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szakmai vezető, Windows Server 2008 
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A változás tekinthető stabil tényezőnek. 





a egy matematikus vagy egy történelem szakos tanár a szakmájának alapjait vizsgál: 

ja, akkor nyugodt szívvel konstatálhatja, hogy nincsenek megrendítő változások. 

A Pitagorasz-tétel működik ma is, és valószínűleg nem fog kiderülni hirtelen, hogy va- 
lójában Caesar szúrt, és Brutus hunyt el. Természetesen a rendelkezésre álló tudás elmélyítése 
az élet bármely területén valós lehetőség, de az alapok és az alapokból építkező tudásanyag ál 
talában nem vész el, stabilan rendelkezésre áll, akár évszázadokon át is. 

Anélkül, hogy beleesnék az elitizmus csábító csapdájába, bátran állíthatom, hogy mi, in- 
formatikai szakemberek egy másik világban élünk. Először is, ez egy rettentően gyors világ, a 
Mooretörvény kiválóan állja az évtizedek sodrát, és a processzorokon kívül több más terüle- 
ten is igaznak tűnik. De még ennél is fontosabb hogy , mifelénk" gyakorlatilag a változás te- 
kinthető stabil tényezőnek, új termékek, új szolgáltatások, új komponensek, új elvek, se vége, 
se hossza nincs az újdonságoknak - tehát tényleg újratanuljuk a szakmát, sokszor beleértve 
ebbe az alapokat is. 

Ha szűkebb világunkba látó szemmel tekintünk, akkor azt kell látnunk, hogy mostanság 
különösen jelentős változások előtt állunk. Kevesebb mint másfél éve jelent meg a Windows 
Vista, ami a korábbiaktól teljesen eltérő ügyféloperációsrendszer lett, ezért érthetően idő kell 
az érvényesüléséhez - no meg egy jó első szervizcsomag: már itt is kopogtat az ajtónkon. Ami 
viszont nekünk nem kopogás, hanem inkább dörömbölés, az a Windows Server 2008, e szá- 
munk kiemelt témája. Szintén 5 év fejlesztés eredménye ez a termék, emellett az első Windows 
Server R2-változat és a Vista kapcsán szerzett összes tapasztalat és tudás benne van. RODC, 
NAP, Hyperv, DFS-R, ADFS, WDS, IIS7, WSRM, NLB, AD CS, IS RA és WA - és még 
rengeteg újdonság, praktikus és hasznos finomítás, tehát újra rengeteg tanulnivaló. Ehhez a 
magazinon kívül, a következő időszakban megrendezendő előadások, screencastok és online 


cikkek formájában mi is hozzájárulunk. Egy (két) szóval tehát: nincs megállás... 
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E CÍMLAPON 


A CSOPORT- 
HAZIREND 


Adu ász a Windows Server 2008 esetén is. 


engeteg alkalommal kapok olyan - akár egészen összetett - szakmai kérdéseket, ame- 

lyekre egyetlen szóval, azaz brutális egyszerűséggel tudok válaszolni: Csoportházirend. 

Felettébb idegesítő szokásom ez, viszont általában nem tréfálok, a tapasztalatom alapján 
tényleg számos problémát megoldhatunk a házirendopciókkal, és sok-sok időt és energiát meg 
tudunk spórolni az energikus Csoportházirend-használattal. 

Legfontosabb előnye az egy helyről történő, központi kezelés és a hatókör, azaz akár az ösz- 
szes számítógépre és felhasználóra érvényesíthető beállítások lehetősége. A központosítás mel 
lett egy másik lényeges érv (csúnya szóval) az inplementálhatóság, azaz képesek vagyunk-e 
fájdalmas átszervezés nélkül ráhúzni a szervezetünkre egy komplex, de azért igény esetén egye- 
divé is tehető beállításgyűjteményt? Szerencsére igen, ennek több biztosítéka is van, például a 
címtárszolgáltatáshoz hangolt működés és a közösen használt hierarchia. 

Így aztán - akár öt, akár ötezer gép vagy felhasználó esetében - ha van tartományunk, te- 


lephelyünk stb., a Csoportházirend adu ászként az asztalunkon hever, csak fel kell fordítani. 

















Default Domain Policy 
BEN 
Default Domain Policy 
Data collected an: 2006 02.02, 198198:10 show all 
Computer tonfiguration (Enabled] hide 
Windows Settings hide 
security settings s haw 
Administrative Templates hide 
Hetwork/Link-Layer Topology Discovery show 
Metwork/Hetwork Connectioms, Windows Firewall bomain Profile show 
Metwork/Metwork Conmections "Windows Firewalléstandard Profile shaw 
System shaw 
systemyűaraup Policy show 
User Confeguration (Enabled) hide 
Windows Ssettings hide 
Remote Installatiom SETVICES s haw 











1. kép. A szimpla vistás GPMC-ben is látható, hogy van Central Store-unk (a kép egy Windows 2003-as tartományban 
készült) 


— Xx 
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Használhatjuk sokféleképpen, átfogó megol 
dásként vagy kiegészítő eszközként, a fókusz 
lehet az operációs rendszer - vagy a rendszer- 
komponensek, vagy éppen az egyéb kiszolgá- 
ló termékek -, de gyárthatunk egyedi sablo- 
nokat, azaz testre szabott beállításcsomago- 
kat is. No és persze ne feledkezzünk meg a 
munkaállomások és a felhasználók környe- 
zetének kialakításáról, illetve bizonyos op- 
ciók kikényszerítéséről és/vagy elrejtéséről 
- hiszen ez az a terület, ahol valószínűleg a 
legtöbbet tudunk spórolni az idővel és az 
energiával. 

A Csoportházirend evolúciója a Windows 
2000 Server/Professional párossal kezdő- 
dött (ami előtte volt, arról inkább hallgas- 
sunk). E két operációs rendszer viszonyában 
körülbelül 630 beállítás állt a rendelkezé- 
sünkre, ami megdöbbentően nagy mennyi- 
ségnek bizonyult akkoriban. Azóta viszont 
minden  operációsrendszerwáltáskor, illetve 
szinte minden szervizcsomag esetén növeke- 
dést lehetett tapasztalni, amely egyrészt az 
egyre , okosabb" opciók kiötléséből, másrészt 
a szaporodó új komponensek lehetőségeinek 
lefedéséből következik. Ma (még a Windows 
Server 2008 előtt), a Vista-tartományban 
használható házirend opcióinak száma 2400 
körüli (XPSP2-vel pedig körülbelül 1800), 
szóval bátran mondhatjuk, hogy eléggé apró- 


lékosan szabályozható. 


WS08-újdonságok 


A ,fejlődés folyamatos" kijelentés közhely- 
nek számít ugyan, de igaz. Gondolkodjunk 
logikusan: a Csoportházirend a kliensekben 
megtalálható komponensek és szolgáltatá- 
sok lehetőségeinek a szabályozását jelenti. 
Ha újabb és újabb elemek jelennek meg egy 
újabb operációs rendszerben, ezeket célszerű 
- majdhogynem kötelező - lekövetni a házi 
rendopciók között is. Ez pontosan így volt ed- 
dig is, sőt egy-egy operációs rendszer szerviz- 
csomagja vagy akár egy-egy új Office-verzió 
kapcsán is. Ezért van az, hogy a WSOS-ban 
már alapértelmezés szerint is 3000 körüli op- 
cióról beszélünk. Ez mindenféle szempontból 
irdatlanul, áttekinthetetlenül sok, de szeren- 
csére a bővülő opciókon kívül - hosszú idő 
után először - jó pár kellemes és kényelmes 
változást tapasztalhatunk a működéssel, a ke- 
zeléssel, illetve a felügyelettel kapcsolatban 


is. Az újdonságokat első körben felsorolássze- 
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rűen szeretném bemutatni, majd rátérünk a 

részletezésre is: 

a (Central Store; 

m az új GPMC; 

m szűrés, kommentek, valamint az ,AlIl 
Settings" nézet; 

un starter GPO-k; 


a Group Policy Preferences. 


A Central Store 


Vizsgáljunk meg első körben egy olyan vál 
tozást, amely nem kizárólagosan a Windows 
Server 2008-hoz kötődik, azaz Windows 
2000/2003 esetén is lehetséges bevezetni, 
de ha már jelenleg is vannak Vista-klien- 
seink és/vagy ha majd Windows 2008-szer- 
vereink is lesznek, mindenképpen célszerű 
lesz használni. Messziről kell elkezdenünk, 
mivel a Central Store kialakításának az egyik 
előzménye a Vistában debütált új házirend- 
sablon-formátum, az .admx és a hozzá pasz- 
szoló nyelvi sablonok, azaz az .adml fájlok 
megjelenése. 

A hagyományos, már az NI-kben is megta- 
lálháató cadm formátumú sablonok finoman 
szólva számtalan hiányossággal küzdenek, 
ezek egyike az a SYSVOL mappa túlterhelé- 
se. Azaz ha egy tartományban létrehozunk 
egy új csoportházirend-objektumot, akkor, 
ha esik, ha fúj, a GPO mappájába az alapér- 
telmezett .adm fájlok, azaz az Administrative 
Templates szakasz sablonjai automatikusan 
bemásolódnak. Ez összesen 45 fájlt jelent, 
a Windows Server 2003 SP2 esetén, körül 
belül 4 megabájt méretben, teljesen üres álla- 
potban - többször tíz, esetleg még több GPO 
esetén (akkor is, ha egyetlen beállítást te- 
szünk meg), számolnunk kell az újabb 4 me- 
gabájttal. Replikáció, telephelyek, alacsony 
sávszélesség, mondjam tovább? Pazarlás, az 
biztos. Nevet is adtak ennek a jelenségnek, ez 
az úgynevezett SYSVOL Bloat. 

Nos, a Vistától kezdődően a gyári sablo- 
nok összmérete nem, a registry alapú műkö- 
dés szintén nem, ellenben a sablon formátu- 
ma és mennyisége megváltozott. 132 darab 
XML alapú, tartalmában a nyelvi elneve- 
zésektől teljesen elválasztott .admx fájlunk 
van a WindowsXNolicyDefinitions mappá- 
ban minden egyes Vistán, illetve Windows 
Server 2008-ON: 

Plusz ugyanebben a mappában lehetnek 
még további mappák is, a nyelvi fájloknak 


(.adml]), amelyekből értelemszerűen szintén 
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132 darab van. Ezek elnevezése nem tetsző- 
leges, a mappa neve kötelezően csak az adott 
nyelvre egyértelműen utaló rövidített válto- 
zat lehet, például En-US, hu-HU stb. 

Nos, el is érkeztünk végre a lényeghez, ha 
vesszük a bátorságot, és ezt az egész szerke- 
zetet (a PolicyDefinitions mappát) bemásol 
juk a tartományunk PDC FSMO-val rendel 
kező DCjére, a STSVOL mappába, akkor 
nincs sablontöbbszörözés, nincs pazarlás, ki 
sebb a replikációs forgalom, mindenki örül. 
Konkrétan a következő helyre kell másol 


nunk ezt a nevezetes mappát: 
SYSVOLYsajat.domain Policies 


A másolásba vegyük be a tartományunk- 
ban lévő összes nyelvű Vista vagy Windows 


2008 saját .adml állományait is az említett 


E oz 


lálható blogról letölthető: http://www.gpo- 
guy.com/cssu.htm. 

Egyetlen megjegyzést fűznék még hozzá 
a sablonváltozáshoz. Ha ugyanis rendelke- 
zünk saját .adm sablonokkal, amelyeket sze- 
retnénk a jövőben is használni, és nem va- 
gyunk XML-guruk, akkor nekünk találták ki 
az ADMX Migrator segédprogramot (http:// 
tinyurl.com/ydbóub). 


A GPMC új változata 


A lassan másfél éve publikus Vistában is 
megtalálhattuk a Group Policy Management 
Console nevezetű MMC-t, azaz már csak 
a régi motorosok emlékeznek arra, amikor 
még külön le kellett tölteni és telepíteni 
minden gépre ezt a csomagot, ha a nagyon 
egyszerű alapértelmezett GP Object Editor 

(gpedit.msc) nem bizonyult elég- 















































2. kép. Szűrés, nagyon alaposan 


mappákon keresztül. Ha majd frissíteni kell 
(például a Vista SPI jelenleg 134 darab sab- 
lonfájllal rendelkezik), akkor pedig csak fe- 
lülírjuk, és kész. Innentől kezdve az újabb 
operációs rendszerek automatikusan észreve- 
szik majd, hogy van központi tároló, és nem 
is használják majd a helyben letett sablonfáj- 
lokat egyáltalán. 

A Central Store kialakításához a kézi má- 
solás is működik és támogatott (KB929841), 
de ha ez bármilyen okból nem megy, van 
hozzá egy segédeszköz is (Vista Central Store 


Creator Utility), amely a következő címen ta- 





e. ] nek (nem bizonyult, ez tény). Ma 
Select options below to enable and change or disable types of global filters that már viszont integrált, a WSOB- 
kh 4 will be applied to the Administrative Templates nodes. vö B 
j ban elsődlegesen tehát ezt a ke- 
Klasse ááá retprogramot használjuk, igaz, 
itt is telepíteni kell a Server 
Managed: Configured: Commented: 
ké j me ü ev Managerrel - a modularitás el 
veinek megfelelően (leszámítva 
[7lEnable Keyword Fitters a forest root DC-t, amelyre a 
BRET ren t tapasztalataink szerint felkerül 
Within: [Policy Settng Tie — [lExplainText — [Z] comment automatikusan).  Kliensoldalon 
ellenben kicsit cifrább a helyzet, 
[9] [) i il ú ke 
etülöttttsaletsáketáltetl átült mert a Vista alapból tartalmazza, 
Select the desired platform and application filter(s): k ső 5 5 ve 
a i a Vista SPLből viszont kikerült. 
ude settings that match any of the selected platforms. y 
L IMicrosoft Windows 2000 Service Pack 1 a se Ennek több oka is van, például 
L IMicrosoft Windows 2000 Service Pack 2 ( dearAl ) All 8 8 é 
L IMicrosoft Windows 2000 Service Pack 3 6 az, hogy a Vistaféle GPMC-nél a 
: L IMicrosoft Windows 2000 Service Pack 4 E § Er K 8 
E1-ElMicrosoft Windows Server 2003 family WSO8-féle UJ abb, és többet tud, 
; L IMicrosoft Windows Server 2003 5 ; 2 sé k 
MMicrosoft Windows Server 2003 R2 viszont azért ne csüggedjünk: az 
Microsoft Windows Server 2003 Service Pack 1 v kát ; 
icrToso indowsSs server ervice Fa új , Adminpackot" a WSOS8-cal 
kálseni [ntüttáeei együtt érkező RSAT (Remote 
Server Administration 1ools) 


tartalmazza, tehát ha a rendszer- 

gazda a saját gépére felrakja ezt 

a csomagot, akkor az összes többi felügyeleti 
eszköz mellett az új GPMC-t is használhatja. 
(Megjegyzés: azért ne feledkezzünk meg 
arról sem, hogy az RSÁI-ot - és így az új 
GPMC-t - jelen helyzet szerint kizárólag a 
Vista SPl-re lehet feltenni, tehát a kör bezá- 


rult, frissítsünk!) 


Keresés, szűrés 

Nos tehát, melyek azok az előnyök, ame- 
lyek miatt megéri ilyen bonyolult módon 
előkészíteni és körbejárni a GPMC hasz- 


nálatát? Például a keresés vagy inkább szű- 
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rés. Sok éve és sok mindenre használom 
a Csoportházirendet, de azért van, hogy 
egy ismerős opciót percekig keresek feldúl 
tam de a 2213-as tanlolyamon — a kezdeti 
Csoportházirend-kábulat után - a hallgatók 


magyarázatokban, illetve a felhasználói meg- 
jegyzésekben is kereshetünk (ezek miatt lát 
szik annyiféle találat a 2. kében a , firewall" 
szóra). Ráadásul tovább szűkíthetünk, egy 


terjedelmes listából az operációs rendszer, a 


első és teljesen logikus kérdése is 


zel kapcsolatos. No és ez per- 
sze még ennél rosszabb len- 
ne a WSO8-ban, a több mint 
3000 OpCIÓ miatt. 

Még abban az esetben is, 
ha a Vista-házirendből meg- 
ismert módon itt is nagyon 
részletes a szerkezet, azaz egy- 
egy — csoportházirend-objek- 
tumban, az Administrative 
Templates-en belül a , System" 
és a , Windows Components" 
alatt sok és értelmesen elne- 
vezett ágra bomlik a tartalom. 

De ez nem elég, jó párszor 
előfordul, hogy egy-egy kom- 
ponenssel kapcsolatos beállí- 
tások eltérő helyeken is meg- 
találhatok, és pont a miatt az 
egyetlen más helyen megtalál 
ható plusz beállítás miatt nem 
működik a jól kitalált , felhasz- 
nálókínzó" elképzelésünk. 

Szóval, ha minden egyes 
opciót szeretnénk látni, ami 
például a ,firewall"-lal kap- 
csolatos, akkor az új GPMC- 
ben rá tudunk keresni erre 
(az Administrative Iemplates 
szakaszon belül), azaz kiszűr 
hetjük ezeket az opciókat egy 
egyéni nézetbe (jobb gomb: 
Filter Options). Ilyenkor csak 
azok a tatolókilátszanak ar bal 
oldali keretben, amelyek a ke- 
resett szavakat magukban fog- 
laló opciókat tartalmazzák. 


A Filtering panelt jobban 


mindig ez- I szervizcsomag vagy akár a különböző kom- 








-! Group Policy Management Editor 
File Action View — Help 


a o] HIH B] BH AIT 


iz Default Dornain Policy [W508-DCI fenestra.local] Policy 
a. el Cornputer Configuration 
a Palicies 






oftwa 
TI Windows Settings 
adi La Adrnirustratrve Ternplates: Folicy definitions (ADB 
ad a Metwark 
ad G Network Connections 
a [84 Windows Firewall 
(Z Domain Profile 
HE atandard Frofile 
ad g aystem 
(g Remote Assistance 
a [d Windows Components 
HE security Center 
ad HE Windows Rernote Management Wink] 
(4 WinRM Service 
(3 Windows Update 
a All Settings 
b Preferences 
ng User Configuration 





3. kép. A szűrés eredménye a bal oldali keretben 





i 
torkos 


ma [dx 


. 2 Group Policy Management 
2 File Action View — Window Help 


tal] H(HXlialHE 


roup Policy Management 
4 Forest: fenestra.local 











Default Domain Policy 




















Scope ! Details ! Settings ! Delegation 








! 3 Domains 
4 33 fenestra.local Domain: fenestra local 
sz! Default Domain Policy 
( CL ÖOwner: Domain Admins (FENESTRAXDomain Admins) 
(3) Domain Controllers Created: 12/23/2007 9:52:32 PM 
(HI RODCs 
Hi SRVs Modffied: 145/2008 9:05:56 PM 
a (5 úr esése ÉDKtS User version: 1 (AD). 1 (gysvol) 
(zf Default Domain Controllers Po Computer version: 26 (AD), 33 (sysvol) 


Default Domain Policy 


Hi 





CE; WMI Filters Unigue ID: (31B2F340-016D-11D2-945F-OOCO4FB984F9) 
3) Starter GPO ; 
áj Me e ZSzAztset GPO Status: (Enabled 7] 





jé Group Policy Modeling 
EE Group Policy Results 


Keszitette: 

GAL Tamas 
2008.02.01 
06-20-555-5555 


gtamasSsuselinux com 


























4. kép. Könnyű eligazodni a GPO-k között is 


megvizsgálva találhatunk jó pár érdekessé- 
get. Szűkíthetjük a keresést az ,igazi", azaz 
a menedzselhető opciókra, vagy mondhat 
juk azt is, hogy csak azok a beállítások érde- 
kelnek bennünket, amelyekhez már koráb- 
ban hozzányúltunk, de szűrési opció lehet a 
felhasználói megjegyzések megléte is (erről 
majd később). 

Ha kulcsszót írunk be, akkor nemcsak az 


adott beállítás szövegében, hanem a gyári 
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ponensek kiválasztásával. Szóval a Windows 
2000 óta várjuk a keresés/szűrés lehetőségét 
a Csoportházirendben, rengeteg ideje nélkü- 
lözzük már, de most végre megkaptuk - rá- 
adásul eléggé kimerítő módon. 

A keresés, szűrés, rendezés témaköréhez 
tartozik még két újdonság is. Az egyik a ko- 
rábban már említett felhasználói megjegy- 
zések bevitelének lehetősége. Minden egyes 


opcióhoz szabadon fűzhetünk hozzá megjegy- 


CNN Re 
S 


zéseket, ami elsőre nem tűnik valami nagyon 
fontos dolognak, pedig az. 

Ha többen hangoljuk a Csoportházi- 
rendet, akkor - lelkiismeretes munkát, ren- 
des kommentezést feltételezve - mindig tud- 
ni fogjuk, hogy ki és miért állította be az 
adott opciót. De tegyük a szívünkre a kezün- 
ket: ha csak egyedül konfigurálunk, akkor 
is emlékszünk arra, hogy egy februári ködös 
péntek estén, három évvel ezelőtt miért állí- 
tottuk be ezt vagy azt? Én nem szoktam, ezért 
aztán néha vad fejtörésbe kezdek - amire így 
talán nem lesz szükség. 

Egyébként az Administrative Iemplates 
szakaszon kívül még egy helyen használ 
hatjuk ezt a lehetőséget, az adott házirend- 
objektum tulajdonságai között, ami szintén 
hasznos lehet egy-egy nagyobb szervezetben. 
Arról már ne is beszéljünk, hogy az előb- 
bi kommentek .cmtx, az utóbbi pedig .cmt 
formátumban (Notepaddel szerkeszthetően) 
megtalálhatók az adott GPO mappájában, 
a SYSVOL-on belül. Egy másik lehetőség az 
összes létező opció egyetlen listába zsúfolása 
(AII Settings). Ez szintén egy Administrative 
Templates hatókörű művelet, külön a gépek, 
illetve külön a felhasználók esetén. 

Ilyenkor a körülbelül 1400 darab, nagyjá- 
ból egyforma opciót a jobb oldali keretben 
láthatjuk, alapesetben ábécé-sorrendben, de 
van lehetőség rendezni az opció állapota, az 
esetleges kommentek vagy az elérési útvonal 
szerint is. Ráadásul nem egy passzív listát ka- 
punk, hanem bármelyik elemre kattintva 
rögvest szerkeszthetjük is az opciót (koráb- 
ban elfelejtettem jelezni, hogy ez a szűrés ese- 
tén is ugyanígy van). 

Az Explain text, azaz a gyári , magyará- 
zó" szöveg kibővítése is ehhez a témához 
tartozik még, soksok helyen újraírták, értel 
mesebbé és használhatóbbá tették, ergo ér- 
demes időnként megnézni. (Megjegyzés: ha 
valamivel ezekben nem értünk egyet, hibát 
találunk benne, vagy jobbat tudunk írni, 
akkor a Group Policy Ieam szívesen fogad- 
ja az alternatívákat a gptextXOmicrosoft.com 


e-mail-címen.) 


GPMC — Startup GPO 

Képzeljük el, hogy szükségünk van 5 darab 
GPO-ra, amelyekben egyenként 100-100 op- 
ciót fogunk beállítani. A 100-ból 50 ugyanaz 
lesz (mert mondjuk ezek a céges alapkövetel- 


mények), a maradék 50-nek viszont teljesen 


Microsoft TechNet 
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eltérőnek kell lennie. Mit csinálunk? Régóta 
vannak már sablonjaink (lásd: Security 


Templates MMC) a Csoportházirendhez, de 


ezek biztonsági sablonok, az Administrative 


ehhez is). Ezután elkezdhetjük létrehozni az 
első sablont, amelyben láthatóan nincs is 
más, mint a két Administrative Iemplates 


szakasz. (Azért ne becsüljük le ezt a jelen- 








Setting 


State 

(E) Do not allow Flip3D invocation Enabled 

(E) Do not display Server Manager automatically at ... Enabled 

E] Windows Firewall: Protect all network connectio... Disabled 

E] Windows Firewall: Protect all network connectio... Disabled 

IE] Allow printers to be published Enabled 

Apply the default user logon picture to all users Enabled 

z]) Turn off Autoplay Enabled 
Access data sources across domains Not ERNEK 


Access data sources acros in h 
Access data sources acro 
Access data sources acro 


Setting Comment 


SSZNEZZEEZSZE TT PTTFRETTÉPTT? 
Do not allow Flip3D i invocation esegena 


Comment Path 4 
Yes Windows ComponentsADesktop Windot 4 
Yes System Server Manager 
No "NetworkiNetwork ConnectionstWindoi 
No "WNetworkiNetwork ConnectionstWindor 
No NPrinters 
No Control Panehser Accounts 
No Windows ComponentsttutoPlay Polici 
No VANAK Componentsnternet Explore 
de - meeeg ponentstnternet Explore 


E. Pmponentsinternet Explore 


bmponentsŰnternet Explore 





Access data sources acro 


Gt GI GIF Ea FR EG 


Access data sources acro És Do not allow FHiip3D invocation 


1 


Access data sources acro 


Pmponentsnternet Explore 
bmponentsÜnternet Explore 
bmponentsÜnternet Explore 





Access data sources acro Policy Setting Comment 


Jozsi voltam, 2008. januar 32ben. 
Utalom ezt az opciot, ezert allitottam be. 


Access data sources acro 
Access data sources acro 
Action on server disconne 
Activate Shutdown Event 
Add a specific list of searc 
Add Printer wizard - Ne 
Add Printer wizard - Ne 
Add the Administrators 56 
z] Add-on List 

Iz] Admin-approved behavio 


Gt a E Er Gr Gr) EGT 


HD 


[ 


Administratively assigned 


[ez 


All Processes 
-) All Processes 
-) All Processes 


Previous Settint 
-) All Processes SERT etüing 





TT EEEE 





Pbmponentsnternet Explore 
pbmponentsŰnternet Explore 
b mponentsUnternet Explore 
line Files 


PmponentsÜnternet Explore 


Profiles 

pPmponentsÜnternet Explore 

b mponentsUnternet Explore 
ffline Files 
bmponentsŰnternet Explore 
Pmponentsinternet Explore 
Pbmponentsnternet Explore 
Pbmponentsinternet Explore - 

















4, Extended A Standard / 


) p 


Cancel 








5. kép. All Settings nézet, kommentek szerint rendezve és egy fontos megjegyzés az adott beállításon 


Templates szakaszra nem vonatkoznak, ne- 
künk pedig kifejezetten a gépek és a fel 
használók környezetével és a komponensek- 
kel kapcsolatos konkrét beállításokra lenne 


szükségünk... 


leg körülbelül 2700 opciót tartalmazó részt!) 
Ha megtesszük a szükséges alapbeállításokat, 
és bezárjuk az új sablonunkat, akkor egy új 
GPO készítése előtt akár választhatunk is e 





Nos, a Windows Server 


2008-tól kezdve használhat 


. Group Policy Management (a (e Illes] 
2 File Action View Window Help - [8] 


to] HEH Al a] [d 








1] 




















, Group Policy Management 
A Forest: fenestra.local 
a (34 Domains 
a Zj fenestra.local 


juk erre a célra az úgyneve- 
zett Starter GPO-kat. Ezek is 
egyfajta sablonok, amelyeket 


(Hi CLIs 
nekünk kell előzetesen és egy- E] RODCs 
7. , ő (Hi SRVs 

szer elkészíteni (a rendszerrel 
f ClisSsPO 


egy darab sem érkezik, ez is 


Ún Um 


E WMI Filters 


eltérés a biztonsági sablonok- — zammanyersel 


kal összehasonlítva). Az új 
GPMC-ben külön menüpon- 

EA Group Policy Results 
tot kapott a Starter GPO sza- mr ü 


CR Sites 








kasz, és ha elvándorolunk ide, 


GE Default Domain Policy 


(HI Domain Controllers 


a (B Group Policy Objects 

zf Default Domain Controll 
zf Default Domain Policy 
FA GPO Sablon01 


A GPO Sablon02 


57 Group Policy Modeling 






Starter GPOS in fenestra local 
Contents l Delegation 


















Name Type Created 
BAGPOo Sablon01 Custom 2/2/2008 5:21:55 PM 
FGPO Sablon02 Custom 2/2/2008 5:27:33 PM 
















VETETT KEMEENTEKI 


New GPO 


Name: 
New Group Policy Object 












Source Starter GPO: 
(none) 


GPO Sablon01 
GPO Sablon02 














1 [gyen NM szal 











l Load Cabinet... je ] 





















akkor első lépésben engedé- 
lyeznünk kell a Starter GPO 
mappa létrehozását (Create Starter GPOs 
Folder gomb, a SYSVOL-on belül ugyanúgy 
létrejönnek majd a GUID-dal jelölt mappák 


JANUÁR-FEBRUÁR 


6. kép. A Starter GPO felhasználása 


sablonok közül kiindulópontként egyet, és 
máris lesz, mondjuk - a példa szerinti hely- 
zetben - 50 beállításunk. 


DE 
p. A 

/ 

LE/A NT 


E 


Szeretném felhívni a figyelmet a piros ke- 
retben szereplő két nyomógombra. Szerepük 
fontos, mivel a hordozhatóságot szolgálják, 
azaz ha egy Starter GPO-t elmentjük .cab for- 
mátumba, akkor egy másik rendszerben is 
elérhetővé tudjuk tenni a , Load Cabinet" pa- 
ranccsal. Ezek ismeretében szimpla ügy lesz 


felszerelni magunkat néhány hasznos Starter 


GPO-val. 


Group Policy Preferences 

A Microsoft 2006 őszén megvásárolta a 
Desktop Standard nevű céget, amelynek 
volt egy remek alkalmazása - lehet, hogy is- 
merős többeknek, ez volt a PolicyMaker. 
Nos, ezt az alkalmazást jelentősen átírták és 
testre szabták, majd teljesen beépítették a 
Windows Server 2008-ba (illetve az RSATba 
is), és immár Group Policy Preferences néven 
fut. Annyira fontos és annyira más, hogy a 
GPO-kban egy teljesen külön főágat kapott. 
Még akkor is így van ez, ha összesen csupán 
körülbelül 90-100 opciót tartalmaz, tehát a 
mennyiséget tekintve nem mérhető össze a 
hagyományos házirendekkel. De más szem- 
pontból sem, hatása ugyanis nem kötelező 
a felhasználókra nézve, hanem csak ajánlás- 
nak szamit tazaztastelhasznaló ühasakatas 
megváltoztathatja az általunk előre definiált 
beállítást. 

Természetesen ugyanúgy központilag han- 
goljuk, és ugyanúgy fÍrissülhet is (a klien- 
sen 90-120 percenként), ráadásul külön-kü- 
lön van itt is gép/felhasználó hatókör (bár 
a hasonlóság az opciók típusa és értelme 
között azért jóval kisebb mint az alapházi 
rendeknél). 

Amit még meg kell jegyeznünk, hogy 
ha egy hagyományos házirendopció és egy 
Preferences opció , összeakad", akkor mindig 
a hagyományos , nyer", de ez logikus is. 

A GPP rengeteg olyan kellemes lehető- 
séget ad a rendszergazdák kezébe, amelyek 
eddig kimaradtak a hagyományos háziren- 
dekből, beszéljünk tehát tételesen ezekről, 
először a számítógépekre vonatkozó opciók 
közül a Windows Settings" körben. 

Environment szakasz. Létrehozhatunk, 
módosíthatunk, kicserélhetünk és törölhe- 
tünk környezeti változókat. 

Files és Folders. Létrehozhatunk, módo- 
síthatunk, frissíthetünk és törölhetünk fájlo- 
kat és mappákat! Mindkét szakaszban számos 


lehetőség van a létrehozás után a mappák és 
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fájlok tulajdonságainak megváltoztatására is, 
valamint például törlés esetén is válogatha- 
tunk a lehetőségekből. 

INI Files. Létrehozhatunk, módosítha- 
tunk, kicserélhetünk és törölhetünk .ini fáj- 
lokat, némi befolyással a szerkezetre is. 

Registry. Szintén minden alapművelet el- 


végezhető a registry esetén is, sokféle érték- 





EJ ClisGPO [W508-DCI1 fenestra.local) Policy 
4 Fk Computer Configuration 

p TE Software Settings 

p TE Windows Settings 


Administrative Templates: Policy 
b (21 Windows Settings 


b (RA Control Panel Settings 


a 42 User Configuration 
(E Software Settings 
(E Windows Settings 
p TE Administrative Templates: Policy 


1 Windows Settings 


Control Panel Settings 











7. kép. Policies és Preferences 2x is egy-egy GPO-n belül 


típust érintve - szemben a régi sablonok fa- 
pados lehetőségeivel. 

Sőt, elindíthatunk egy varázslót is, amely- 
lyel csatlakozhatunk a távoli géphez, így 
, élesben" tudunk változtatni a registry érté- 
kein (ehhez persze a távoli gépen futnia kell a 
Remote Registry szerviznek, a Vistán ez már 
nem alapértelmezett). 

Network Shares. Létrehozhatunk hálózati 
megosztásokat is, minden egyes, a klasszikus 


módon is elérhető jellemzőjével együtt, sőt az 


eket és az adatforrásokat is konfigurálhat 
juk, ugyanúgy mint az ODBC panelen a 
Vezérlőpultban. 

Devices. Engedélyezhetünk vagy tiltha- 
tunk eszközmeghajtókat a class ID-jük alap- 


ján, nagyjából hasonlóan, mint 


CNN Re 
S 


Panel" szakasz, de ennek (néhány esetben 
szintén szenzációs) részleteitől már megkímé- 
lem a kedves olvasót, nézzék meg önszorga- 
lomból, megéri. 


Attól viszont nem, hogy bemutassak még 





[Ess 


az eredeti (Vista-) házirendben. 


Folder Option. Kicsit más, 


57 Targeting Editor 


New Item s 3 Add Collection ! Item Options " - 4 3 4 Ba (E " X Delete J € Help 


ms smssnyi 





mint fent, a fájltípusok, a fájl 
összerendelések körét szélesít 
hetjük vagy szűkíthetjük. 
Local Users and Groups. 
Minden ()), amit egyébként tu- 


dunk művelni a helyi felhaszná- 





(B the NetBIOS computer name is Vista-EEN 

ap AND the operating system is Windows Vista Gold 

e AND the CPU speed is greater than or egual to 1000 MHz 

47 AND the portable computer docking state is Docked Undocked 

(8 AND the terminal session is Terminal Services with Application name -— Word 
Bé) AND the language is Hungarian (Hungary) 

ké AND a PCMCIA slot is present 

EI AND free disk space is greater than or egual to 40 GB on the E: drive 

AND the time is between 9:00 AM and 5:00 PM 








lókkal és/vagy a csoportokkal. 
Persze először létre kell hozni Parameter 


ezeket, bár az Administrator 


és a Guest felhasználókat alap- 





értelmezés szerint is tudjuk ke- 





Application name a 


Word 


Parameter value 


A Terminal Session targeting item allows a preference item to be applied to users only if the prol 
services session with the settings specified in the targeting item. Additional information... 








zelni így. 
Hihe- 


tetlen, de igaz: innen indulva képesek le- 


Network Options. 


szünk minden részletre kiterjedő VPN. és 
DUN-kapcsolatokat létrehozni a kliensen. 
Mindenre gondoltak, eldönthetjük, hogy egy 
vagy az összes felhasználónál jelenik majd 
meg a kapcsolat, elérhetők a tárcsázási, a hi- 


telesítési és egyéb opciók 







































2! Group Policy Management Editor fa ](E](z] 15. Ha már van VPN-kap- 
File Action View Help 
tels ülmasiAMTIRO 1 csolatunk azon a gépen, 
(zf ClisGPO [WS08-DCI fenestra.local)] aA . . 51 
4 fk Computer Configuration "akás atai av amelyiken konfiguráljuk a 
TA Policies Fri I 
4 Preferences GPPt, azt például beim- 
ol ztegátasi KEST sal portálhatjuk, elképesztő... 
jé Folders 94 . 
Tee ájp Power Options. Itt 
A Registry 7 elR7. , 
63) Network Shares 7 i gyárthatunk opciókat és 
[él Shortcuts EH Ke SystemCertificates a 
ú ő H-T (IA Windows k TF . , 
a NSB 6-CEI Windows NT sémákat az energiaellá- 
a 45 Gt 5-MEd Currentversion 
olicies á-TÉ fr B SÖPNT TÉSSS A 
(E Preferences b — Ma tas opciókörében (csak 
ME Printers y 8 B 
üs a GE Windows XP esetén). 
M [eb] (Default) REG. SZ (value not set) a 8 
[a REG. DWORD amámi (1) Printers. TE IP- és lo- 
já e ! , 8 
SOFTWAREPolicies MicrosoftiWindows NTYPrinters kális (!) nyomtatókat hoz 
öz z hatunk létre. LPT/USB/ 
OZ 7 i j 
si COM-portokat, IP-címet 





8. kép. Működik a klienshez kapcsolódó éles registry-varázsló 


Access-based Enumeration (magyarul: csak 
azt látja a felhasználó, amihez van jogosultsá- 
ga) opciók is elérhetők. 

Shortcuts. Szintén elérhető minden alap- 
művelet a parancsikonokkal kapcsolatban is. 

Van folytatás is még a gépek házirendjé- 
nél, és eza Control Panel kör, ahol a követke- 
ző szakaszok találhatók meg. 

Data Source. Létrehozhatunk, módosít 
hatunk, frissíthetünk és törölhetünk DSN- 


jd 


és minden más nyomtató- 
tulajdonságot is konfigu- 
talhatúnk 1Et. 

Scheduled Tasks. Létrehozhatunk, módo- 
síthatunk, frissíthetünk és törölhetünk időzí- 
tett feladatokat. 

Services. A rendszerszolgáltatásokat illető- 
en is számos lehetőségünk van, igaz, ez nem 
sokban különbözik a szimpla házirend esetén 
ismerős opcióktól. 

Ezek mellett a felhasználókra is van egy- 


egy , Windows Settings" és egy , Control 


9. kép. Szerfelett granuláris feltételek — csoportba szedve 


egy fontos komponenst, az úgynevezett 
Target Editort, amelyet minden beállításnál 
megtalálunk (a Common fülről érhető el), 
és amellyel egyszerűen és látványosan szűkít 
hetjük a beállított opciónk hatókörét. A 9. 
képhez értelmetlen feltételeket szedtem ösz- 
sze, a lényeg nem is ez, hanem a sokszínűség, 
még legalább háromszor ennyi lehetőség van, 
ezeket nagyon egyszerűen összepakolhatjuk 
egy közös feltételrendszerré (szóval nem kell 
a WMLvel kínlódnunk). Ami lemaradt a 
képről, pedig különösen fontos, az a szűrés 
lehetősége a csoportokra, illetve az egyéni fel 
használókra. 

Már csak egyetlen fontos kérdés maradt 
hátra a GPP-vel kapcsolatban: mely kliense- 
ken fog működni alapértelmezés szerint, és 
mi lesz a többivel? 

A válasz nem olyan rossz, mint amire szá- 
míthatnánk: Windows 2008-on csont nél 
kül, a Vista RIM, XPSP2 és Windows Server 
2003 SPI/SP2 esetén egy letölthető úgyne- 
vezett ClientSide Extension (CSE) segítsé- 
gével működik a GPP. A Vista SPI, illetve 
az XPSP3 és a CSE viszonya beétaállapotuk 
miatt jelen pillanatban meg kérdéses, de a 
hírek szerint a várakozásunk ellenére ezek- 
ben sem lesz benne gyárilag (de szerintem a 
MU/WU/WSUS szórásba egyébként is be- 
kerül majd). 

Gál Iamás 
(v-tagak omicrosoft.com) 
Microsoft Magyarország 
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Már jó pár éve szemezek Ovidius Atváltozások című könyvével. 


Szívesen elolvasnám, de valahogy mindig tolódik a terv. Most 


éppen a Windows Server 2008 Failover Cluster tunkciójának 


megismerése köti le az időmet. Bár amilyen átváltozáson átesett ez 


a szoftverkód, akár még a fent említett műben is szerepelhetne. . . 


ert minek is nevezhetnénk azt a változást, amelynek révén a telepítési, a hálózati, a 
lemezkezelési, (29uorum-kezelési és a GUI alrendszert is teljesen újraírták? Még a szol 
gáltatás - bocsánat: képesség (feature) - neve is megváltozott. Már nem Microsoft 
Cluster Server (MSCS) vagy Server Cluster, hanem , Failover Cluster". Kattintgatva az MMC 


ikonjain, azon gondolkodtam, mi nem változott? 


Egy hajdanvolt cikksorozat — Failover Cluster 2002-es szemmel 
No, igen. Az, hogy milyen volt a fürtszolgáltatás, egész jól tudjuk. A TechNet Magazinnak meg- 
lehetősen kedves ez a téma: 2001-ben és 2002-ben mindösszesen tizenhárom cikkben taglaltuk 
a szoftver képességeit. (A , véletlen" úgy hozta, hogy a jelen írás és a korábbi cikksorozat szerző- 
je azonos.) Van tehát egyfajta előkép, és bár szerettük, azért kritikával is illettük mindazt, amit 
láttunk. Íme, két idézet az egykori tapasztalatokról: 

, A Cluster telepítésének inkább NI4-es formája és érzete van, mint Windows 2000-es. Ez a 
, gyanú" később igazolódni fog: A Windows 2000-ben nagyon sok mindent átírtak, és nagyon s0- 
kat fejlesztettek, beleértve a Cluster szolgáltatást is, mégis maradt jócskán tennivaló a következő 
kiadásig." (2001. december — II. rész) 

, A fürtszolgáltatás, úgy tűnik, mindig egy lépéssel az újdonságok mögött jár. Az eredeti Win- 
dows 2000 fürt, akárcsak a korábbi NI8 verzió, lemezszignatúrákat használ, nem ismeri a dina- 
mikus diszkeket, a lemezcsatolás módszerét, ragaszkodik a lemezek betűjeleihez, NTILM hitelesítést 
alkalmaz, az FRS szolgáltatással hadilábon áll, még a telepítése is olyan NI4 szagú. A sok hiá- 
nyosságból most az egyik, a hi- 





telesítés, kicsit közelít a normá- 


s Windows 2000 szintjéhez." ÚT relore Gstetezeert [E 


(2002. decémber — XIII. rész) 
Ezeken túl 2002 decembe- 
rében - a további idézeteket 
ellhagyva — hiányoltuk a DES- 
FRS-Cluster integrációt, az 
IPv6-támogatást, a GPI-leme- 
zek használatát, a kizárólagos 
Kerberos hitelesítést, és a clus- 
ter.llog dokumentálatlanságát. 
Összegezve: a fürtszolgáltatás 
bevezetésekor mindeddig egy 


nagy kompromisszumot kel 


JANUÁR-FEBRUÁR 





d 
z SZE ún 
5 a Nodes 


"0 Demoliustér has 1 appkcatonazsérviőés ánd 2 nodes 


Name: Demoliuster demo kocsi Networks: Ouster intemel, Ouster LAN, Ouster SAN 
Current Host Server: CLUNODEO2 Subnets: 2IPv4 and 0IPv6 

Aavonum Corfiguratton: Node and Disk Majorty ( Öuster Disk 4 ) 

Application Alert: none? 





Corfigure high avadabátty for a pecék vervice or aopication. add one or more ververs nodes). or migrate regouroe group 
setings írom a ciuster running Windows Server 2003 

















1. kép. A Failover Custer megújult MMC konzolja 


lett kötnünk. A magas rendelkezésre állásért 
cserébe bizonyos innovatív képességekről le- 
mondtunk, ami főleg a biztonságot növelő ké- 
pességek esetén fájt, és lépten-nyomon hiány- 
zó puzzle-darabkák akadályozták, hogy teljes 
értékű rendszerünk legyen. Mindennek fé- 
nyében különösen izgalmas, mit hoz a 2008- 
as esztendő Windows-verziója. 

Visszatérve az MMC kezdő képernyőjéhez: 
a sokéves tapasztalat ellenére, az első percek 
ben elvesztem. Ez lenne a Failover Cluster? 

tt mát semimiésímes "úgy E MmIMENTEDENE 
Aztán némi akklimatizáció után rájöttem, 
nem olyan ijesztő a dolog. Bár külsőleg min- 
den új, az alapok változatlanok. 

Az architektúra elve továbbra is a ,semmi 
sem közös" (shared-nothing). Az építőkövek 
az erőforrások, az erőforrás-csoportok és a 
függőségek. A mechanizmusok lényege ma- 
radt a régi: átköltözés (failover), visszaköltö- 
zés (failback), sőt még olyan funkciókat is vi- 
szontláthatunk, mint az IsAlive/ LooksA live. 

Az alapokon túljaázonban áz totrás Forrás 
si, érdemes tehát nem hagyatkozni a régi 
beidegződésekre, a képességek újratanulását 


nem kerülhetjük el. 


Megváltozott környezet — a szerepek 

kiegészítése 

A Failover Cluster megértését kezdjük a kör 
nyezetének megértésével. A Windows Server 
2008 elhozta számunkra a szerepek (roles) és 
képességek (features) világát. Már nem egye- 
di szolgáltatásokkal (Windows service) bajló- 
dunk, magasabb fogalmi egységgel, a szerep- 
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pel kell megküzdenünk. Egy , File Server" 
szerep, vagy egy , Print Server" szerep telepí- 
tésekor a rendszer tudja, milyen egyedi szol 
gáltatásokat kell telepíteni. A Failover Clus- 
ter nem szerep, hanem képesség vagy tulaj- 
donság (feature). Önmagában semmire sem 
való; egy konkrét szerepet egészít ki magas 
rendelkezésre állási képességgel. Vagyis, bár 
önmagában telepíthető, az erőforrások csak 
akkor hozhatók létre, ha azok szerepkörét 
előzőleg felraktuk. Példa: a DFS NameSpace 
egy fürtözhető erőforrás, ám ha nem telepít 
jük a File Server szerepkör szerepkör-szolgál 
tatásaként (role service), nem hozhatunk lét 
re ilyen erőforrást sem - végül is érthető. A 
lényeg: a Failover Cluster tökéletesen érti a 
környezetét és annak fogalmait, azokkal szo- 
rosan integrált. 

A fürtadminisztrátorok két szempontból is 
profitálhatnak a fentiekből. Egyrészt nagyon 
jól lehet majd tudni, hogy egy fürttagon , mi 
van tcmt salkontiouració jobban átlátható: 
Másrészt, ha a Failover Cluster mindent ért, 
akkor teljes egészében kompatibilis a , Server 
Core" telepítési móddal is - és valóban: ott 
éppúgy működik, mint a teljes telepítéskor. 
Az első piros pont: a Server Core nyújtotta 
kisebb erőforrásigényről, kisebb sérülékeny- 
ségről, kevesebb hotfixről nem kell lemonda- 
nunk annak érdekében, hogy magas rendel- 
kezésre állásunk legyen. Ugyanakkor ebből 
egy egészen más implementációs kényszer 
megoldás is következik: a Failover Cluster 
parancssori felülete nem Powershell alapú. 
És ezúttal nem a Clustercsapat maradt le. 
Ha a Server Core-támogatás követelmény, a 
parancssori felület szintén, a Server Core-on 
viszont a Powershell (legalábbis a Windows 
Server 2008 verzióban) nem működik, ab- 
ból az következik, hogy a fürtszolgáltatás pa- 
rancssori felülete sem lehet Powershell alapú 
- hiába a WMI-barát szerkezet. 

Végül még egy példa a környezettel való 
összenövésre. Ha létrehoztunk egy magas 
rendelkezésre állású File Server szerepkört 
egy fürtön, majd ezután megosztunk egy 
mappát a Windows Explorer segítségével, a 
megosztás automatikusan fürtözött megosz- 
tás lesz! (Vigyázat! A megosztás már nem erő- 
lortás) A fürt úgyanis tudja, hogy az adott 
lemez, amelyen a megosztás létrejött, melyik 
erőforráscsoporthoz tartozik, tehát magát a 
megosztást is oda helyezi. Vagyis nem fordul 


hat elő, hogy egy fürtön megosztott mappa 


1 


nem fürtözött mappa. És fordítva: nem szük- 
séges a cluster administrator mmc elindítása 
a fürtözött szolgáltatás létrehozásához. Na, 


ez integráció! 


Telepítés 

A fürtöket többnyire ott rontották, ront 
ják el, ahol ez először lehetséges, a telepítés- 
nél. Vagy azért, mert eleve nem támogatott 
hardver szolgál alapul, vagy mert nem értik 
pontosan a fürt működését, és rosszul para- 
méterezik azt. A Windows Server 2003-ba 
a korábbi kiadásokhoz képest sokkal szo- 
fisztikáltabb telepítő, pontosabban iniciali 
záló modul került, de még itt is érvényes 
asszabdaly Sesak azokos teyattótolsszáranazó, 
Clusterkompatibilitási listán szereplő alkat 
részekből építkezhetünk. 

Jelentem, ennek vége. A telepítés során egy 
nagyon alapos, összetett rendszer esetén akár 
egy óránál is tovább futó validációs teszt el- 
dönti, hogy az általunk fabrikált gépezeten 
működik-e majd a fürtünk vagy sem. Ha a 
teszt eredménye szerint működik, akkor sze- 
dettvedett hardver ide, HCL oda, az egy, a 
Microsoft által is támogatott fürt lesz. 

Sőt! Ha földrajzilag elosztott fürtöt épí- 
tünk és ezért a storage-teszt figyelmezető 
üzenettel fejeződik be, még ebben az esetben 
is a támogatott kategóriába esik a konfigu- 
rációnk. A Cluster HCL pedig füstté vált. 
Nincs többé. Nyomtassuk ki és tegyük el a 
validációs jelentést, mert azt később meg- 
lobogtathatjuk a megfelelő támogatási szer- 
ződés meglétekor. Mindez egyébként azért 
vált lehetségessé, mert mind a lemezkezelés, 


mind pedig a hálózatkezelés alapos revízión 
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Failover Cluster Validation Report 


Node: CLUNODEO1.demo.local 
Node: CLUNODEO2.demo.locai 
Started 12/27/2007 3:15:54 PM 
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2. kép. Validációs teszt — működni fog a cluster 


esett át, a fejlesztők pedig gondosan elimi- 
nálták a hibalehetőségeket, így már belezsú- 
folható egyetlen tesztbe minden szükséges 
ellenőrzés. 

A telepítés folyamata 3-4 lépésből áll, és 
egyszerre végrehajtódik az összes, általunk 
kijelölt node-on. A telepítés most első alka- 
lommal teljes egészében scriptelhető - nagy- 
mértékben javítva ezzel az implementálás 
tervezését, a változáskezelést és a katasztrófa- 
helyzetek megoldását -, és hol máshol len- 
ne erre a legnagyobb szükség, mint éppen a 


fürtöknél? 


Első benyomások — MMC 


A fürtszolgáltatás végre valódi MMC-konzolt 
kapott - eddig egy MMC-t utánzó execállo- 
mány (Apage Satana!) nyújtotta a grafikus fe- 
lületet. A bal oldali fa struktúrája Exchange 
2007-es iskolában nevelkedett fejlesztőkről 
árulkodik: nagyon egyszerű, legfeljebb két 
lépcsőből álló fastruktúra, mindössze öt fő 
ággal: szolgáltatások és alkalmazások (az erő- 
forráscsoportok helyett), fürttagok, tároló al 
rendszer, hálózat, végül pedig a fürttel kap- 
csolatos események. A középső panel teteje 
mindig egy áttekintő táblázatot tartalmaz, 
jobb oldalon pedig a környezetérzékeny me- 
nü, amely minden pillanatban eléggé gazdag, 
úgyhogy a valódi menü használatára alig van 
szükség. Az egész felület letisztult és feladat 
központú. 

A fürt valamely objektumának létrehozá- 
sát minden esetben varázslóval kell elvégez- 
ni. Ez eddig is így volt, legfeljebb a varázslási 
folyamat áttekintése javult, az ablakok job- 
ban magyarázzák önmagukat. Eleinte kell is, 
mert számos objektum kapott új nevet. Az 
erőforráscsoport első hálózati neve például 
, Client Access Point". Ezzel együtt a varázs- 
lókat nem éreztem idegesítőnek. Megvan a 


maguk helye és szerepe. 


A Ovorum átalakulása 

A fürtök eddigi nagy kincse a (?uorum volt, 
amely szerencsés esetben saját lemezen ült, 
és tulajdonképpen eredetileg nem volt más, 
mint egy tranzakciós rendszerrel kiegészített 
registry-hive. Hajdanán egyetlen (Puorum-tí- 
pus létezett, aztán a Windows Server 2003 
megjelenésekor újabb kettő mutatkozott be 
(local (Xuorum, Majority Node Set). Még 
később, az Exchange 2007 megjelentetésé- 
vel együtt a Microsoft kiadott egy fürt , hot 
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s Configure Cluster Ouorum Wizard 


áz Select Auorum Configuration 


Before You Begin 


Select Guorum 
Configuration 


Configure Storage 
Witness 


Read the descriptions and then select a guorum corfiguration for your cluster. The recommendations are 
based on providing the highest availability for your cluster. 
C Node Majority ínot recommended for your current number of nodes) 
Can sustain failures of 0 nodeís). 


(s Node and Disk Majority (recommended for your current number of nodes) 


Can sustain failures of 1 node(s) with the witness disk online. 
Can sustain failures of 0 nodeís) íf the witness disk goes offline or fails . 


Confirmation 


Conrfigure Custer 
Guorum Settings 


C Node and File Share Majority for clusters with special configurations) 


Summary 


kicsit többet ér a fürtta- 
gokénál. A fürt túléli a 
tagjai felének elvesztését, 
ha a tanúlemez műkö- 
dik, illetve a fürt túléli a 
tagjai felének -1 tagnak 
sra kiműlását na at tane 


lemez az örök vadászme- 


C No Majority: Disk Only (not recommended) 


More about ations 





3. kép. A Ovorum típusának kiválasztása 


fixet" (921181), amely varázsolt egy vado- 
natúj (f?uorum-típust. Ez megosztott mappát 
használ ,tanúként" (file-share witness) és a 
Majority Node Setre emlékeztet. 

Nos, a Windows Server 2008-ban a Ouo- 
rum fogalma a korábbiakhoz képest felbo- 
rult. Már nem registry-hive vagy lemez, vagy 
megosztott mappa, vagy többség, hanem 
mindegyik, illetve egyik sem. A legpontosab- 
ban úgy togalmazhatok: a Ouorum annak a 
tudása, hogy mi a Cluster, milyen a konfigu- 
rációja és milyen az aktuális állapota. Ennek 
JELEELÁS HA Ad DILEOKOSAKS vagy JóLttókosa Sa 
(2uorum. Ilyen értelemben mindig csak egy 
(Puorum van, de az lehet elosztott több node, 
megosztás, lemez között. Azt, hogy a fürt tag- 
jai birtokoljákce a megfelelő tudást (értsd: a 
(2uorumot), és így a fürt működőképes-e, 
szavazásos módszerrel döntik el a fürt tagjai. 
Implementációját tekintve a (?uorum négyfé- 
leképpen működhet - azt mondhatjuk, hogy 
négyféle szabály szerint lehet szavazni vagy a 
szavazatokat kiértékelni. 

Úgy érdemes elképzelni ezt, mint egy ská- 
lát, ahol a tengelyen a Ouorum elosztottsága, 
hibatűrése változik. A típusok: 

Node Majority. Ez a változat minden te- 
kintetben megegyezik a korábbi majority 
node set üzemmóddal. Szavazati joguk csak 
a türttagoknak van. Ha a szavazásban a több- 
ség részt vehet, akkor a fürt működik, ha 
nem vehet részt, akkor a fürt leáll. A fürtta- 
gok száma minimalisan 3, maximálisan 16. 

Node and disk majority. Ilyen korábban 
nem volt. Az előző verzióhoz képest szavaza- 
ti jogot kap a tanúlemez (witness disk) - a 
korábbi (?uorum disk megfelelője. Továbbra 


is a többség dönt, de a tanúlemez szavazata 
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Can sustain failures of 1 nodeís) íf the witness file share remains available. 
Can sustain failures of 0 node(s) íf the witness file share becomes unavailable. 


Can sustain failures of all nodes except 1. Cannot sustain a failure of the guorum disk. This 
configuration is not recommended because the disk is a single point of failure. 


c Previous [d Net ]  Cned 


Példa: 


4 tag § tanúlemez. Ha 


zőkre költözött. 


a tanúlemez működik, 
kieshet két fürttag. Ha 
a tanúlemez nem műkö- 
dik, kieshet (4/2) - 1 - 
1 tag. Kéttagú fürt ese- 





tén ez azt jelenti, hogy a 

Cluster túléli a tanúlemez kiesését - feltéve, 
hogy mindkét node hibátlan! 

Node and File Share Majority. Pontosan 


úgy működik, mint az előző esetben, csak a 


TETT SO 7 
egre E 
él ss 


het tanúmegosztás, annak viszont nincs aka- 
dálya, hogy egy másik fürt megosztása legyen 
tanúmegosztás. A tanúmegosztásnak nem 
kell azonos telephelyen lennie egyik fürtál 
lomással sem. 

No Majority: Disk Only. Ez a diktatúra... 
A , szavazás" úgy módosul, hogy csak a tanú- 
lemeznek van szavazata. Amíg a tanúlemez 
plusz egy fürttag él, addig van fürt. A mód- 
szerben nincs semmi új, ez az eredeti (Vuo- 
rum-típus - hátránya, hogy maga a Ouorum 
egypontos meghibásodást jelent egy olyan 
rendszerben, amely az egypontos meghibáso- 
dásokat hivatott kiküszöbölni. 

A modelleket - ha megfelelő számú fürt 
tag rendelkezésre áll - szabadon átalakíthat 
juk egyikből a másikba. Elsőre furcsa, hogy 
az MMC-felületen a hajdani Cluster group 
- az első létrehozott erőforráscsoport, amely 
a Ouorumot tartalmazta - nem látható. 


Végeredményben mégis 





FÉR Failover Cluster Management 


jobb ez így - nem for- 
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dulhat elő, hogy erőfor- 








3. Failover Cluster Management 
d út DemodCluster . demo. local 
- Há Services and Applicatic 
" DemoClusterFS 

d Gá Nodes 


Storage 











esz Summary of Storage 











j CLUNODEO1 st c EE Esett 
, Hi CUNODEO2 4 Total Disks - 3 online Total: 29.99 GB 
(s Storage 2 Available Disks - 2 online Free Space: 29.76 GB 


E (EG Networks 
AH Custer Internal 
AA Custer LAN 
AA Custer SAN 


2 In Use Disks - 1 online 


Percent Free: 99.27 
































rásokat pakolunk bele. 
A fent említett 16 ma- 


Available Capacity- 
Total: 19.99 GB 

Free Space: 19.84 GB 
Percent Free: 99.27 


ximális fürttag minden 


üzemmódban ., elérhető. 





5] Cluster Events zi. 
Witness Disk in Guorum A hálózat 
§ d , , 
Gz Cluster Disk 4 23 Failed CLUNODEO1 ata la ku lása 
Available Storage 
A] Cs Cluster Disk 2 (B Online CLUNODEO1 A (9uorum átalakulásá- 
- 63 Cluster Disk 3 (9) Online CLUNODEO1 08 kn ; 
Volume: (G) File System: NTFS 10 GB(99.27 free) val összevethető válto- 
DemoCiusterFS zások történtek a fürt 
A 66 Cluster Disk 1 (A) Online CLUNODEO1 Keri se É 
Volume: (E) File Svstem NTES —— 10GB(9927 íree ) hálózatkezelési  techni 








4. kép. A custer lemezeinek gyors állapot-áttekintése 


káiban is. Kezdjük az- 
zal, hogy a fürttagoknak 





2 Failover Cluster Management 
7 EZ DemoCluster.demo.local 
- 3 Services and Applicatic 
-(7 DemocClusterFS 
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z CLUNODEO1 
7 CLUNODEO2 
A Storage 
B (E Networks 
AA Custer Internal 
ja Cluster LAN 
3 Custer SAN 
í8] Cluster Events 


Cluster Internal 
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Summary of Cluster Internal 
Custer Intemal has 0 subnetí(s). 

















Statusz Up 
Custer Use: Intemal 





- HAH CLUNODEOT - Local Area Connection 2 
Adapter: Microsoft VMBus Network Adapter £2 
IP Address: fe80::807e:dc94:c5ac:b4837-11 

- HH CLUNODEO2 - Local Area Connection 2 
Adapter: Microsoft VMBus Network Adapter £2 
IP Address: fe80::39ea:d4c5:7 1bb:aeef/.11 




















nem kell statikus IP-cím- 
mel rendelkezniük. Ízlés 
kérdése: van, aki a sta- 
tikus címekre esküszik 
a szervereknél - én in- 


kább a DHCPE:szerver le- 
foglalt IP-címeit preferá- 


(9) Up Node:CLUNODEO1 


lom. Az központosított 


is meg vezérelhető is. A 
(£) Up Node:CLUNODEO02 


Failover  Cluster mos- 








5. kép. A cluster belső hálózata 


tanúlemez helyett tanúmegosztást (file share 
witness) használunk. Ezt a (Puorum-típust 
vezette be a Microsoft a 921181-es hotfixszel. 
Földrajzilag elosztott fürtök esetén érdemes 


használni. Jegyezzük meg, DFS.link nem le- 


tantól kielégíti az álta- 
lam jónak vélt módszert. 
Ha a külső fürtcímeknél 
ez nem is mindenkinek vonzó, a fürtön belü- 
li (intra-cluster) hálózattal egész biztosan sen- 
ki sem akar foglalkozni. Ezután nem is kell. 
Úgy működik az APIPA, hogy azt nem jelzi 


problémának. 


Le 
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Kell ennél több? Íme: vadvízi evezősök tisz- 
tán IPv6-konfigurációt állíthatnak be - mit 
is idéztünk a cikk elején? És még folytat 
hatjuk: teljes a NetBIOS-függetlenség; für- 
tök közötti forgalom teljes titkosítása; műkö- 
dik a tisztán Kerberos hitelesítés, NILMvI, 
NITLMVv2 igény szerint kihajítható. 

Régi vesszőparipám is teljesült: a fürtö- 
zött megosztások egyenrangú részei lehetnek 
egy DFS-névtérnek, különösen, ami a repli- 
kációt illeti. Így végre felépíthető egy olyan 
DFS-névtér, amelynek minden megosztása 
magas rendelkezésre állású, azonos tartalom- 
mal. Ezt éppen a Windows 2000 Advanced 
Serverbe álmodtam bele hét ével ezelőtt! 

A hálózatkezelés területén az ire a pontot 
a földrajzilag elosztott fürtök létrehozásának 
lehetősége teszi fel. Elvileg ennek eddig sem 
volt akadálya - ha a hálózati switcheket és az 
útválasztókat úgy tudtuk konfigurálni, hogy 
a fürtök azonos VLAN-ba kerüljenek, és azo- 
nos IP alhálózatból kapjanak címet. Ezután 
már csak , imádkozni kellett", hogy a hálózat 
válaszideje ne növekedjék egy szint fölé, amit 
egy fürt már nem tolerált volna. Erre a mu- 
tatványra nem lesz többé szükség: a fürttagok 
gond nélkül külön alhálózatban is működ- 
hetnek - hála a (parancssorból) konfigurál 
ható heartbeat időtúllépésnek. 


A lemezkezelés átalakulása 

A sok újdonság között személyes kedvenceim 
a lemezkezeléshez kapcsolódnak. Ezt a kom- 
ponenst is alapos revíziónak vetették alá, né- 
ha egészen meglepő eredményeket produkál 
va. De hogy jobban értsük, tekintsünk vissza 
egy kicsit a múltra. 

A fürtszolgáltatás - ahogy azt már említet 
tem - a ,semmi sem közös" elven épült fel, 
és ez igaz a lemezekre is. A semmi sem közös 
elv az amúgy közös diszkalrendszernél azt je- 
lenti, hogy semmit sem birtokolnak közösen 
egyszerre a fürt állomásai. A lemezeket mint 
erőforrásokat lefoglalják, és egy viszonylag 
bonyolult algoritmust építettek a szoftverbe, 
hogy a lemezek átadását, hiba esetén pedig 
az erőszakos átvételét kezeljék. Amikor erő- 
szakos átvételről írok, egyáltalán nem túlzok. 
A Windows 2000-fürtök egyetlen lemez át 
vételét SCSI Bus reset paranccsal oldották 
meg. Mintha egy fa egy ágának lemetszését 
úgy végeznénk el, hogy motoros fűrésszel 


fentről lefelé végigsimogatnánk az egész fát. 


Ez jól működött 1997-ben a külső házas Par 
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allel SCSI Direct Attached Storage rendsze- 
reknél, de a mai konszolidált SAN-világban 
roppant barbár megoldás. A Windows Server 
2003 kulturáltabb módszert alkalmazott, de 
végső esetben még eleresztett egy bus resetet. 
A Windows Server 2008 viszont már finom 
úriember, a bus reset számára ismeretlen fo- 
galom. A lemezek lefoglalására a , Persistent 
Reservation" módszerét használja - tároló-al- 
rendszer vásárlásakor ezt a képességet tessék 
tehát árgus szemekkel figyelni, amennyiben a 
fürtszolgáltatás építését is a fejünkbe vesszük. 

Egy kis kitérő. Fürtöt építünk. Mit is jelent 
ez? A fürtépítés állandó harc az Achilles-sar- 
kok, angolul Single Point of Failure (SPoF) 
ellen. Van már kiszolgálónk, összekötjük egy 
új tárolóalrendszerrel. Összekötjük? Hány- 
szor? Ugye, legalább duplán, az SPoF elleni 
védelem jegyében. Ahh, ettől a pillanattól 
kezdve viszont már több útvonalon is elérhet 
jük ugyanazokat a lemezeket, pontosabban 
[ENO Kat 

De ha már két storage-kontrollerünk van, 
nem lenne érdemes megosztani közöttük a 
terhelést a hibatűrés megtartása mellett? A 
Windows Server 2008-ban implementáltak 
egy új tulajdonságot, amely , Multipath [/D7 
(MPIO) névre hallgat, és a fenti probléma- 
kört oldja meg igen magas szinten. Az MPIO 
nem feltétele a fürtszolgáltatásnak, de terve- 
zési szempontból a két komponens kéz a kéz- 
ben jár: rendes cluster MPIO-t használ. 

Az MPIO ismeri az összes aktuális és 
modern . storage-szabványt,  felsorolássze- 
rűen: Fibre Channel (FO), iSCSI és Serial 
Attached (SAS). Éles szeműek rögtön lát 
hatják, egy valami hiányzik, a Parallel SCSI. 
És igen, elérkeztünk a tényleges mondani 
valónkhoz. A Parallel SCSI támogatása ki- 
került a fürtszolgáltatásból. Fáj ez nekünk? 
Elsőre úgy tűnik, igen. A Parallel SCSI egy 
kiöregedő szabvány, vagyis egyre olcsóbb, és 
milyen jó lenne, ha ilyen nagyon olcsó vasból 
építenénk legalább próbálgatásra vagy tesz- 
telésre fürtöt. Nem fog menni. Aztán, vir- 
tuális SCSLkártyákat használhatunk virtual 
server vendéggépben is, és mindeddig ez volt 
a fürtépítés módja virtualizált környezetben. 
A Windows Server 2008-tól már ez sem mű- 
ködik. Mi az, ami maradt? Tesztelésre, virtuá- 
lis környezetre virtuális iSCSI Target, fizikai 
megvalósításnál pedig az FCASCSLSAS hár 
masból bármelyik. 


(Lássuk be, azért nem volt ez olyan várat 


lan húzás. x64 platform alatt már a Windows 
Server 2003-nál sem lehetett PSCSLt hasz- 
nálni, ráadásul az ipar is szép lassan kidobja 
ezt a szabványt, ott az utód, a SAS. Viszlát 
deszka-cluster, viszlát PSCSI! Béke poraira!) 

Térjünk vissza a fürt és a lemezek kezelé- 
sének témaköréhez. Hat évvel ezelőtt pana- 
szoltuk, hogy a dinamikus lemezekről mit 
sem tud a fürtünk. Nos, a témába vágóan egy 
jó és egy rossz hírrel szolgálhatok. A rossz, 
hogy a Windows Server 2008 sem ismeri a 
dinamikus lemezeket. A jó hír, hogy ez nem 
baj... Mire kellenének a dinamikus leme- 
zek? Alapvetően két célt szolgálhatnak: egy 
adott partíció dinamikus növelése oldható 
meg velük, illetve szoftveres RAID-tömbö- 
ket hozhatunk létre a segítségükkel. Ez utób- 
bi fura igény lenne. Szoftveres RAID-et már 
évek óta nem láttam használni, olyan olcsó 
lemeztömböt hardvereszközzel megvalósíta- 
ni. Ha viszont valaki tényleg templom egere, 
akkor kizárt dolog, hogy türtszolgáltatásra 
van szüksége. A fürtszolgáltatás ugyanis ön- 
magában sem olcsó dolog - ergo, aki létrehoz 
egy fürtöt, annak már nem fájhat a hardve- 
res RAID-beruházás sem. Marad a partíció 
növelésének igénye. Erre a céltáblára három 
golyóval is lőhetünk. Először is, ma már a vir- 
tuális lemezek világát éljük, a LUN-ok, ame- 
lyeket a fürt tagjai fizikai lemeznek látnak, 
valójában évit tását es solyannyitast hogy Fa 
Microsoft Storage szerverben az iSCSI Target 
ténylegesen egy VHD formátumú állományt 
ajánl ki. VHD? Akkor az később növelhető 
is. És ha már megnöveltük a VHD-t, akkor 
egy diskparttal a partíció is kihúzható. Ehhez 
nem kell dinamikus diszk. 

Jó, maradt a basic lemez. Ez azt jelen- 
EL hosy maradt ar diszkek szignatútasalapú 
azonosítása? És a diszkek cseréje továbbra 
is rémálom? Egyáltalán nem. A lemezeket a 
fürt mint korábban c tovabbra 15 a parti 
ciós táblába írt szignatúrák alapján azonosít 
ja - elsősorban. Emellett - és ez az újdonság 
Sazotol szabvány ingüity patamcsat is hasz: 
hálja a túrt. SA parancsra a választ a storage 
kontroller adja meg, és egy adott LUN-t lehet 
azonosítani vele. A LUN a kiszolgálóból néz- 
ve egy diszk. Mivel ez két egymástól független 
módszer, a Windows 2008 szempontjából 


3 


ugyanaz a , fizikai lemez" azonosítása, a me- 
tódusok egymás tartalékai lehetnek. Ha egy 
lemez nem található a szignatúra alapján, de 


az SES ágúttveműködük a tÜtt autonratt 


Microsoft TechNet 
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Available Storage 








4 Cs Cluster Disk 2 
Gala zást 








(9) Online 
etet 













Bring this resource online 
Take this resource offline 


DemoClusterf-S 





Change drive letter 











-] 3 Cluster Disk 1 
Volume: (E) 





(9) Online 





Show the critical events for this resource 





Show Dependency Report 








File System: NTFS 


üzemmód (maintenance 


CLUNODEO1 


mode) rejtelmeibe. Bár 
CLUNODEO1 


elsőre azt hittem, hogy ez 
a Windows Server 2008 


újdonsága, rá kellett jön- 


CLUNODEO1 
10 GB (99.27 free ) 








More Actions. . . 


nöm, nem így van. 








Delete 


Sirnulate Failure. of this resource 


A Windows Server 





Properties 


Move this resource to another service or application 


2003 SPI verziójában 





Help 














implementálták. (Részle- 





6. kép. Hibás lemez javítása 


kusan javítja a szignatúrát, és fordítva. Persze 
nem zárható ki az sem, hogy teljes katasztrófa 
történt, és a teljes lemezalrendszer megsem- 
misült szignatúrástul, Inguiry-adatostul. A 
fürt erőforrásai leállnak 
ugyan, de megfelelő kon- 
figuráció esetén (Node 
and disk majority) a fürt 
szolgáltatás még ezt is 
túlélheti. Ha azután új- 
raépítjük a rendszerün- 


ket, a fizikai lemez erő- 





lortastat kattintva, : maje 
a Repair disk "batran 
Csot választva már rá ís 
mutathatunk, hogy a fürt lelke, vagyis a defi- 
niált erőforrás milyen testbe (értsd: tényleges 
LUN-be) költözzön. Szép, ugye? 

Három további, lemezekkel kapcsolatos 
fejlesztést kell megemlítenünk, ebből ket 
tőnek előzménye is van. A GPT támogatást 
már 2002. végén is ismertük, az akkor még 
.Net Server leánykori néven futó, később 
Windows Server 2003 x64-es fürtjeinél citál 
tuk mint újonnan támogatott partíciós for- 
mátum. Jelentem a GPT nagykorú lett, a fürt 
minden platformja ismeri! Mi a GPT? GUID 
Partition Table - a Master Boot Record levál 
tását szolgáló módszertan. Mindenki, aki 2 
terabájtnál nagyobb partíciókat szeretne ke- 
zelni, GPT.formázás után kiált majd. És hol 
lenne a legnagyobb jelentősége e szabvány tá- 
mogatásának, ha nem éppen a legfontosabb, 
legnagyobb rendszerek esetén? 

Talán nüansznyi újítás, de jegyezzük meg: 
a tanúlemez nem igényel betűjelet. Mivel a 
nagyméretű Exchange- és SOLfürtök meg 
olyan lemezkiosztást szeretnek, ahol a cím- 
keként használt betűk pillanatok alatt el 
fogynak, adott esetben ez az egyetlen betűjel 
jól jöhet. 

Most pedig szeretném bevezetni az ol 


vasót a lemezekre vonatkozó karbantartási 


JANUÁR-FEBRUÁR 


fuailahbhle Storage 
üluster GFYoupn 
DemoClusterF35 


tekkel a 903650-es cikk 
szolgál.) Mi a karbantar- 
tási üzemmód? Azt jelenti, hogy a fürtszolgál 
tatás mind a négyféle (LooksAlive, IsAlive, 
SCSI Reserve, Private Sector) lemezellen- 


őrzési funkcióját felfüggeszti, a fizikai lemez 


ca. Administrator: Command Prompt 


(zsllserssdministratorócluster group 
Listingy status for all available resource groups: 


status 


CLUHODEHI 
CLUHODERBZ 


CLUHÖDEHI LR nt - 


fs Iserxssfdministratopr? 





7. kép. Parancssorból is gyönyörűen látszik minden 


erőforrást , online" állapotban tartja, továb- 
bá lehetővé teszi, hogy más processzek kizá- 


rólagosan lefoglalhassák a lemezt. Nem kell 
Ta e edu lást isa 


I új (Fé Dependency Report 


server2" reguired dependencies are IP Address. 


sr 


fepresents "AND" relationship: all child resources must be on-line 





8 
File Server And 
FileServer-(DemoClusterF SXCiu 
ster Disk 1) 
g— [a 
File Server And 


FileServer-(Server2)Y(Cluster 
Disk 1) 


IP Address 
IP Address: 10.0.0.104 





fepresents "OR!" relationship: at least one child resource must be on-line 








[mlEl] Xx 


itt bonyolult dologra gondolni: chkdsk. Ha 
nincs maintenance mód, akkor csak a fürt 
szolgáltatás teljes leállításával lehetne hibaja- 
vítást végezni. Különben már az első ellenőr 
zés elhasalna, mire a fürt ijedten átküldené 
a teljes erőforráscsoportot a másik node-ra 
- lekaszabolva ezzel a chkdsk-et. 

A karbantartási üzemmódnak van még 
egy járulékos haszna: ez az összekötő kapocs 
a hardver alapú lemezpillanatkép (snapshot) 
visszaállításához. A folyamat egyszerű: 

x A függő erőforrásokat egy ügynök leállítja. 

a Karbantartási üzemmódba teszi a lemezt. 

nu Exclusive lockot alkalmaz. 

an Kicseréli a fizikai lemezt egy korábbi pilla- 
natfelvétellel. 

a Feloldja a kizárólagos hozzáférést. 

a Befejezi a karbantartási üzemmódot. 

a Elindítja a függő erőforrásokat. 

Ez több, mint amire számítani lehetett. A 
Windows Server 2008-nak csak grafikus fe- 
lületet kellett biztosítania - megőrizve termé- 


szetesen a szkriptelési lehetőséget. 


Erőforrások és erőforráscsoportok 

Évekkel ezelőtt tapasztaltuk már: erőforrá- 
sok születnek és elhalnak. Kikerült az IIS, 
jött helyette a Generic Script. Eldőlt - hiába 
hiányoltuk -, a WDS magas rendelkezésre 


rite [tú C; WserstAdministrator JAppDatalLocaliTemp!DependencyReport.mht s] 6911 XI ÍLive Search 


tt-B)-é 


d va 
[gi 
Network Name IP Address 


Name: DemoClusterFS IP Address: 10.0.0.105 


sz 


Plhnysical Disk 
Custer Disk 1 


, Az L 


—-e e 


IP Address 
IP Address: 10.0.0.22 


Network Name 
Name: Server2 





8. kép. Pontos függőségek beállításának lehetősége 
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állását az NLBS, nem pedig a failover cluster 
biztosítja. Van ugyanakkor húsz alapértelme- 
zett erőforrás, ezek közül a Distributed File 
System, a File Server, a File Share Witness, 
az IPv6 Address, az IPv6 Tunnel Address, a 
Microsoft iSNS és az NFS Share részben vagy 
egészben új erőforrástípusok. 

Sem a súgó, sem az MMC-felület explicit 
módon nem használja azt a kifejezést, hogy 
erőforráscsoportsablon, de tulajdonképpen 
mégiscsak létezik ez a fogalom. Ha létre sze- 
retnénk hozni egy új , services and applica- 
tion" objektumot - ez a hajdani erőforráscso- 
port -, akkor a varázsló első lépésénél 13-féle 
, út közül választhatunk, s ezek nem mások, 
mint sablonok" Van köztük DEE S DEE 
Other Server () és Virtual Server is — ez 
utóbbi a Hyper VVintegrációt mutatja. 

Az erőforrások közötti viszony legjelentő- 
sebb változása a függőségeknél tapasztalható. 


Korábban a többszörös függőségek kizárólag 


volna el a helyes irányt, hanem... de lássuk 
előbb, mit hiányoltunk a korábbi verziókból. 

, Végezetül feltehetjük a kérdést, hogy va- 
jon elégséges információval és eszközökkel ren- 
delkezünk-e ahhoz, hogy hatékonyan hárít- 
suk el a fürt hibáit. Úgy gondolom, hogy a 
Microsoftnak még sok tennivalója van ezen a 
téren. Két lehetséges úton haladhat a cég a jobb 
hibafelderítés elősegítésére. Az egyik egy refe- 
renciakönyv elkészítése a lehetséges naplóbe- 
jegyzésekhez [...] A másik 


CNN Pe 
S 


zésre állású szolgáltatás esetén, akkor az az 
auditálás: ki, mikor és mit végezett el azon a 
gépen vagy fürtön. Persze ehhez vannak üze- 
meltető szoftverek, mint például a System 
Center Operations Manager, de azok is leg- 
inkább az operációs rendszer beépített audi 
tálási képességeire hagyatkoznak. Nos, az 
első lépéseket megtették a fejlesztők, a fürt 
re vonatkozó események (csoportmozgatás, 


erőforrás-létrehozás stb.) auditálhatóvá vál 





út az, ha szorosabb integ- 
rációt valósít meg a fürt 
és a Windows 2000 ese- 
ménynaplózó alrendsze- 
re között [..] A naplózási 


16, Informatior 
6 Informatior 
8 Informatior 
6 Informatior 
4 Error 

15, Informatior 
181, Informatior 
6 Informatior 
6 Informatior 
6 Informatior 
18, Informatior 
8. Informatior 
8 Informatior 
81, Informatior 
8 Informatior 
16, Informatior 


Nodes: 


szinteket komponensen- 
ként lehetne meghatároz 
ni, és ha szükség van rá, 
akkor bekapcsolva egyre 


részletesebb eseménysort 
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Cluster Events (352 events) 


[ae d ás CÁg E 
zzz ESETET 3 


Select the criteria for which you want to display events. 


CLUNODEO1 .demo local 
CLUNODE02 demo local 


Microsoft-Windows-EventCollector/Operational 


ív Microsoft-Windows-Failoverülustering/Operational 


Microsoft-Windows-Forwarding/Operational 
Microsoft-Windows-GroupPolicy/Operational 


[1 Microsoft-Windows-Help/Operational 


Microsoft-Windows-Http Service/ Trace 
Microsoft-Windows-Intemational/Operational 


Read only cluster events from the System log 
Critical M Error MM Waming 





I Informational I" Verbose 


—— ee 


Enter ID numbers and/or ID ranges separated by comma. To exclude 
criteria , type a minus sign first. For example: 1, 3, 5-99, -76 


fEvents On r] 1/28/2008 9 [12435 PM -] 


láthatnánk. 0 (2002. én0- 
Farkasokkal 
táncoló XII. rész) 


6 Informatior 
16, Informatior 
161, Informatior 
8 Informatior 


ÉS kapcsolaton alapultak - vagyis elég volt est 
vent IDs: 


megállnia egyetlen erőforrásnak a sok közül, ! vember — 


hogy a függőségi láncban tőle függők mind 


megálljanak. A Windows Server 2008-ban 
viszont az erőforrásfüggőség definiálásakor 
VAGY kapcsolatot is létrehozhatunk. Egy 
hálózatinév-erőforrás függhet két IP-cím- 
től is. Az egyik leállása VAGY kapcsolatnál 
nem okozza a hálózatinév-erőforrás leállását. 
Alhálózat cseréje során ez kifejezetten jól jö- 
het. Apropó: függőséget - szemben a korábbi 
verziókkal - működő erőforrásoknál is meg- 
adhatunk. Elvégre legalább a fürtszolgáltatás 
maga ne okozzon leállást... 

Végezetül egy különös erőforráscsoportra 
is felhívom az Olvasó figyelmét. A korábbi 
fürtökön az egyetlen azonnal létrejövő erő- 
forráscsoport a Cluster Group volt a Ouo- 
rummal. A Failover Cluster ezt kiegészíti még 
eggyel, amelyet , Available Storage Group" 
nak hívnak, és ahogy a neve mutatja, azokat 
a lemezerőforrásokat tartalmazza, amelyeket 
még egyetlen ,valódi" csoporthoz sem ren- 
deltünk hozzá. Miért fontos ez? Azért, mert 
így a fürt létrehozásának pillanatától minden 
lemezerőforrásra egyértelműen foglalt. Az új, 
rejtett csoport létrehozása a lehetséges rejtett 


hibák elkerülését jelenti. 


, , , 
Eseménynapló-kezelés 
Őszinte leszek: az eseménynapló-kezelés válto- 
zása okozta a legtöbb frusztrációt a számomra. 


Nem azért, mintha a fejlesztők nem találták 
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A próféta szólt az írás- 
ból aharomtentirelképe 
zelésből kettőt viszont 
láthatunk a  Failover OpCode: Info 


Clusternél. Az MMC fa- 


Strüktúra öt fóágaából az 








já Cluster service successfully brought the clustered service or application Cluster Group" online . 





utolsó az eseménykeze- 
lés. Módunk van a kon- 
zolból való kilépés nélkül megtekinteni a 
fürttel kapcsolatos összes eseményt. Melyik 
eseménynaplóból? , Melyikből szeretnéd?" - 
jöhetne a válasz helyett a visszakérdezés. Itt 
is a Windows Server 2008 alapjai köszönnek 
vissza. Eseménynapló már nemcsak három- 
négy-öt van, hanem sokkal több és sokkal 
részletesebb. A fejlesztők tehát ránk bízzák, 
hogy milyen eseményeket szeretnénk össze- 
valosatat asmisabálenmteó 48 sent aj adr 
kezdetben nincs ötletünk - fogadjuk el az ő 
eseményszűrő alapbeállításaikat, nem fogjuk 
megbánni. 

És az integráció itt még koránt sem ért vé- 
get. Minden csoporthoz, erőforráshoz a lehet 
séges tevékenységek között kiválaszthatjuk a 
hozzá tartozó kritikus és figyelmeztető ese- 
mények lekérdezését. Ez egy nem módosítha- 
tó lekérdezés, de nem is baj: szerepe, hogy az 
adott objektummal kapcsolatos hibaelhárí 
tást a leghatékonyabban lehessen elkezdeni. 


Ha van fontos dolog egy magas rendelke- 


9. kép. A bőbeszédű, de szűrhető eseménynapló 


tak. Ezenfelül minden fontosabb tevékeny- 
ség, amelyeket varázslók is segítenek, a win- 
dowsvclustervweports mappában jelentéseket 
hagy - vagyis nemcsak az ellenőrizhető, mi 
történt, hanem az is, hogyan. 

És mi lett a cluster.log-gal? Nyugdíjba vo- 
nult és átadta helyét a Windows Server 2008 
biztosította Event tracine "szolgáltatásnak. 
Mindeddig ez a képesség az egyetlen kivétel, 
amely nem érhető el a fürtszolgáltatás konzol 
jából. A , Reliability and Performance" kon- 
zolban láthatjuk a Data Collection Sets 2 
Event Irace Sessions ágon belül. Láthatjuk, 
pontosabban megnézhetjük, hogy az élő ese- 
mények kezelése vajon fute. Az eseményeket 
magukat nem - ahhoz egy tracerpt nevű pa- 
rancssori eszköz áll a rendelkezésünkre. Ha 
ez nem tetszik, akkor még fordulhatunk a 
cluster.exe megfelelő kapcsolóihoz, amely az 
általunk paraméterezett módon és helyre egy 
olyan logot generál, amilyen korábban a clus- 


ter.log volt. Hogy megnézhessük végre. 
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A rövid próbálgatás némi hiányérzetet ha- 
gyott bennem. A hétköznapi események , kéz 
alatt" vannak, ez jó. Az adott objektumhoz 
tartozó gyors eseménymegtekintés briliáns 
ötlet. Az események leírását is megfelelőnek 
éreztem. A diagnosztikai elemzés azonban 
nehézkesen indul, és éppúgy nincs tudás- 
bázis cikkekkel, referencialeírásokkal megtá- 
mogatva, mint a korábbi verziókban. 
Ezenfelül még egy dolog frusztrált. Az 
MMC-konzol közepén elhelyezkedő belső fej- 
léc automatikusan jelzi a kritikus és figyelmez- 
tető üzenetek számát. Ez még rendben is lenne 
- de az üzenetet nyugtázni és eltüntetni már 
nem tudtam, márpedig az nagyon zavaró, hogy 
EE 


Failover Cluster Management [ed TS eT án r I l 
§ ÜZ BEGSEZSSGGEZÜa E moCluster.demo.loca 


A B Services and Applicatic 
F DemodClusterFS 








a Summary of Cluster DemoCluster 





B (ZA Nodes 9 DemoCiusterhas 1 applications/services and 2 nodes 

Hl CLUNODE01 

El CLUNODEO2 Name: DemoCiuster.demo local Networks: 

(G Storage Current Host Server: CLUNODEO2 Subnets- ; 

A Es] Networks ül B ag b 

HÜ Custer Internal Guorum Configuration: Node and Disk Majority ( Custer Disk 4 ) 

A Cluster LAN 

Ad Custer SAN 


Application Alert: -nonez 
Recent Cliuster Events! 4. Ciitical:5, Error: 87, Waming: 11 
ín] Custer Events 
:t Configure 


10. kép. A korábbi hibák sokáig láthatóak maradnak 


egy problémát megoldottunk, de az esemény- 
naplóban fellelhető hibát x ideig még a fejlécre 
is kivezetik, függetlenül az aktuális helyzettől. 


Egyéb változások 
Sok-sok lelkesítő újdonságról, fejlesztésről 
esett már szó, de biztos vagyok benne, hogy 
az üzemeltetők majdani első számú kedvence 
nincs közöttük. A valószínű győztes egy ap- 
rócska dolog: nincs többé szükség cluster ser- 
vicefiókra! Vagyis, nincs szükség 

a ennek a fióknak a létrehozására; 

m jogosultságainak kezelésére lannak idején 
egy fél cikket rászántunk, hogy megmutas- 
suk, a service account tud nem Domain 
Admin is lenni); 

nm a jelszóházirend meghágására - ha nem le- 
járóvá tesszük a fiók jelszavát; 

nm jelszavának cserélgetésére; 

n hibaelhárításra, ha véletlenül töröltük a 
fiókot, vagy elfelejtettünk időben új jelszót 
adni neki, vagy csak a jogosultságait von- 
tuk meg stb. stb. 

a oh - mennyország! 

Amikor a Windows 2000 Server fürtjeit 
használatba vettük, még a holdban sem volt 
ar S SZWSUS vagy más rautonratikús "elsz 
sítési rendszer. Egyáltalán, a frissítés mint 
olyan, elég alacsony prioritású feladat volt. 


Nem úgy ma. A fürtök azonban speciális 
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bánásmódot igényelnek. Mert teszem azt, 
milyen állapotok keletkeznek, ha egy gépre 
éppen akkor költöznek át erőforrások, mi 
közben hotfixet rak fel. Sokféle, de csak nem 
determinált. Épp ezért kellett bevezetni az 
állomások megállítását (Node Pause) és visz- 
szaállítását (Node Resume). Amíg egy állo- 
más , Pause" állapotban van, addig a meglé- 
vő erőforrásokat futtatja, de új csoportokat 
nem fogad be - egy stabil állapot keletkezik: 
indulhat a frissítés. A , Node Resume" ezt a 
helyzetet szünteti meg. 

Valljuk be őszintén: a fürtök mentése és 
visszaállítása többnyire az ezoterikus témák 
közé tartozott a rendszergazdák számára. A 
fürtön lévő adatokat mentettük persze, de 
a fürtkonfigurációval nemigen lehetett mit 
kezdeni. A system state része, és az bizony 
sokszor nagy gombóc a torokban. No de ne 
bolygassuk a múltat... 

A Windows Server 2008 Failover Clusteré- 
nek mentése egy kicsit már egyértelműbb, 
köszönhetően a (?Ouorum letisztultságának. 
Mivel a Ouorum mostantól kezdve egy el 
osztott valami, a konfiguráció helyreállítása 
S legalábbis a szóhasználatban — nagyon ha 
sonlít az AD helyreállításhoz. Éppúgy, mint 
ott ,Authorative" és , Non-Authorative" 
helyreállítást hajthatunk végre. Az elsőnél 
becsatlakoztatunk egy node-ot a meglévők 
közé, az utóbbi esetben visszaállítunk egy 
fürtöt egy korábbi konfigurációs állapot sze- 


rint. Részletek az RIM megjelenésével. 


Feketeleves 
Minden nagyon jó, minden nagyon szép. 
Tényleg? Ennyire? Bölcs ember tudja: szépség 
és szörnyeteg együtt járnak. A Windows Server 
2008-ban implementált Failover Cluster akko- 
rát ugrott elődeihez képest, hogy a gyökereit 
is elszakította: történetében először nincs le- 
hetőség a rolling upgrade frissítésére. Mi a 
rolling upgrade? Elvileg lehetséges volt, hogy 
egy Windows NT 4.0-val beüzemelt fürtöt át 
állítsunk Windows 2000-re úgy, hogy előbb az 
első node-ot frissítettük, majd az erőforrások 
átmozgatása után a másikat. Azután pedig ezt 
tovább folytathattuk a Windows Server 2003- 
mal. Egyszerre csak egy verziókülönbség volt 
megengedett, a frissítésnek szigorú szabályai 
voltak, de mégiscsak működött. Eddig. 

A Windows Server 2008-cal új korszak 
kezdődik. Az eltérő storage-kezelési mecha- 


nizmus és a hálózat változása bezárta a kapu- 


CNN NR 


kat. Mit lehet tenni? Azért van egérút, a für- 
tök migrációját varázslók segíhetik. Egy dara- 


big. Azután kellünk mi, mérnökök. 


Összefoglalás 
Mielőtt pár szép szóval elbúcsúznánk, még 
egyszer szeretnék idecitálni egy régi-régi cikk- 
ből. Tanulságos. 

, Kényelem kontra biztonság kontra kom- 
patibilitás: A biztonsági tényezők alkalma- 
zásakor sokszor felhívják a szakemberek a fi- 
gyelmet, hogy a biztonság növelése gyakran a 
kényelem és a használhatóság rovására történ- 
het. Biztonságosabb a jelszóval történő azono- 
sítás, mintha ilyen nem történik, de meg kell 
jegyezni a titkos jelsort (kényelem csökkenése), 
és ha tévesen adjuk meg a minket azonosító 
adatokat, a rendszer kizárhat minket (a hasz 
nálhatóság korlátozódik). 

Az üzemeltetési tapasztalatok azonban azt 
mutatják, hogy egy harmadik dimenzió is be- 
folyásolja a biztonsági funkciók bevezetését, 
ez pedig a kompatibilitás. A rendszer egyes 
elemeit más-más csoportok fejlesztik, akik el- 
térő sebességgel képesek a központi biztonsági 
igényekhez alkalmazkodni. A fürtszolgáltatás 
például nem képes a Kerberos hitelesítésre, 
így akik ezt a szolgáltatást igénybe veszik, nem 
tudnak tisztán Kerberos rendszert bevezetni." 

Úgy érzem, hosszú oldalakon keresztül 
soroltuk azokat a példákat, amelyek alapján 
világossá vált: a Failover Cluster - legalábbis 
a 2008-as verzió nem tartozik a fenti kompro- 
misszumok közé. A fürt és az azon futó alkal 
imazasok mindazt tudjak, amiraz Operációs 
rendszer része - kompromisszumok nélkül. 

A virtualizáció megjelenésével a fürt - 
amely maga is egyfajta virtualizációs technoló- 
Ola oda került ahová való: ném alkalmazá 
sokat biztosít (értsd: nem izolál), hanem azok 
magas rendelkezésre állását teszi lehetővé. 

És a jövő? Szemetek a virtualizációra vessé- 
tek! A Failover Cluster már most is integrált 
a Hyper V-vel, scriptek helyett csupán erő- 
forrásokat kell felvennünk. A jövőben azon- 
ban ennél többre lesz szükség: éles migráció, 
erőforrás-kihasználtság alapú csoport (értsd: 
virtuális gép) mozgatása és vagy még egy tu- 
catnyi egyéb ötletem van, mire lenne szükség 
a jövőben. Úgy érzem, a Failover Cluster csa- 
pata felpörgött a jövendőbeli kihívásokra. 

Lepenye Ilamás 
(tamaskemicrosoft.com) 
MCSE, Microsoft Magyarország 
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Az operációs rendszer frissítése, sémafrissítés és a működési szintek. 


címben említett három téma tekinthető akár egy egységnek is, mivel elvégezve eze- 
A ket, a Windows Server 2008 bevezetésének szoftveres előkészületeit nagyjából meg is 

tettük. Persze pontról pontra követni, kész receptnek venni az alábbiakat nem okos 
dolog. Szinte 100 százalék, hogy a legtöbb esetben, a való világban sokkal összetettebb, bonyo- 
lultabb feladat lesz az áttérés, és természetesen nagyobb mértékben testre szabott is egyben. 
Sok-sok éve gyakorló rendszergazdaként tudom, hogy minden információ, ami a támogató do- 
kumentumokban elolvasható, és így minden, ami ebben a cikkben is szerepel, az maximum 


elméleti alap lehet a sokcsok egyedi rendszer üzemeltetője számára. 


Az operációs rendszer frissítése 
A Windows Server 2008 nyolc változatát az alábbi táblázatban foglaltuk össze. 
Kiegészítések: 
1. A WSOS8 egyik remek újdonsága a SKU Hyper-V-t tartalmaz? 
WS08 Standard (x86/x64) E 
WS08 Enterprise (x86/x6 4) — 
WS08 Datacenter (csak xó 4) 
WS08 Standard (csak xó4) 
WS08 Enterprise (csak xó 4) 
WS08 Datacenter (csak xó4) 
WS08 Web Server (x86/x6 4) ka 


WS08 Itanium Edition (csak 64) — 


Server Core, de ez nem egy különálló termék 
vagy változat, hanem egy speciális telepítési 


mód, amely a Standard, az Enterprise vagy a 


Datacenter változat 32 és 64 bites környezeté- 


ben egyaránt használható. 


kk 


2. A Hyper-V komponens csak x64-es ope- 
rációs rendszerre kerülhet fel. 

3. A WSO8 Web Edition csak helyi SOL- 
támogatással működhet. 

A támogatott frissítési útvonalak szintén 
egy táblázatban láthatók. 

1. Ami rögtön látszik, pontosabban nem látszik a táblázatban, az a WSO03 Web Server válto- 
zat hiánya, de ez nem véletlen, hiszen erről nincs frissítési útvonal, annak ellenére sem, hogy 
WSO8-as változat is van belőle. 

2. Minden felsorolt útvonal feltételezi azt, hogy nem x86-ról x64-re történik az áttérés, mivel 
az ilyen frissítés továbbra sem támogatott. 

3. A Server Core változatra semmilyen operációs rendszerről sem lehet áttérni, még egy 
WSOS8-változatról sem. Sőt, egy működő Server Corett sem lehet frissíteni egyik hagyományos 


változattal sem. 


R. 


Amit futtatunk Amire áttérhetünk 
WS03 R2 Standard Edition 

WS03 Standard Edition $P1 WS08 Standard 
WS03 Standard Edition SP2 WS08 Enterprise 
WS08 Standard RCO 

WS03 R2 Enterprise Edition 

WS03 Enterprise Edition SP B 
NSOG Enfejoíise Elitanopzz 48 lemHIsE 
WS08 Enterprise RCO 

WS03 R2 Datacenter Edition 

WS03 Datacenter Edition SP! GO ADe táe tér 


WS03 Datacenter Edition S9P2 
WS08 Datacenter RCO 


4. Általánosan a Microsoft nem blokkolk 
ja a frissítést a bétaváltozatokról (azaz, akár a 
Beta3-tól végigmehetünk az RTM-ig), de ezek 
a frissítések nem támogatottak, kivéve a bel 


ső és a TAP-ügyfeleket. 


Változások a Windows Server 2008 
telepítésében 

A Vistához hasonlóan a WSO8 telepítése is 
egyszerűbbé vált, persze ez úgy értendő, hogy 
ha nincs szükség rá, akkor alig kell beavat 
koznunk. 

Valamennyire azért muszáj, mert például a 
háttértárakkal variálnunk kell, és ezzel kap- 
csolatban akadnak extra lehetőségeink. 

A telepítés gyakorlatilag három fő részre 
osztható: 


1. A színtiszta operációsrendszertelepítés, 


Microsoft TechNet 





KE CÍMLAPON 






a DVD-s rendszerindítástól a termékkulcs, a 
nyelvi és a billentyűzetkiosztás-beállításig. 

2. Initial Configuration Tasks, a valóban 
alapbeállítások, amelyeket tipikusan egyszer 
használunk (időzóna, AU-kliens, gépnév, há- 
lózat, TCP/IP, RDP, tűzfal stb.) 

3. Server Manager, amely egy rendkívül 
széleskörűen használható eszköz, és amely a 
következő, korábban használatos varázslók és 
MMC-konzolok kombinációja egyben: 
an Manage Your Server Wizard; 

a Configure Your Server Wizard; 
x Add/ Remove Windows Components; 
n Computer Management. 

A Windows Server 2003 SPI-ben megje- 
lent SCW-t (Security Configuration Wizard) 
nem említettem, mivel ennek futtatására 
már nincs szükség - a WSOS szerepkörei és 
szolgáltatásai ugyanis alapállapotban is meg- 
felelő biztonságossággal konfigurált állapot 
ban dolgoznak. 


A sémafrissítés 

Egy új Windowss-szerverváltozattal tipikusan 
együtt jar a cimtárszolgáltatás változása, a kü- 
lönböző kisebb-nagyobb újdonságok megjele- 
nése is. Ezek általában kényelmes és kellemes 


változások, de ez előké- 


kell. Ennek oka az új szolgáltatások és tulaj- 
donságok megjelenése, amelyek új és újfajta 
bejegyzéseket jelentenek a címtáradatbázis- 
ban, tehát a sémában, azaz a címtárban tárol 
ható objektumok definícióinak , tárházában" 
is gondoskodnunk kell a bővítésről. Nincs ez 
másként a WSO8- és a Windows 2000/2003- 
tartományok esetén sem. Szerencsére viszont 
a frissítést nem kézzel kell elvégeznünk, eh- 
hez rendelkezésre áll egy gyári segédprogram, 
az Adprep.exe (ami a telepítő DVD-n meg- 
található). A frissítéshez egy speciális jogokat 
adó csoporttagság is szükséges, konkrétan a 
Schema Admins biztonsági csoport (amely 
csak a forest root domainben van) tagjává 
kell tennünk a bővítést végző felhasználói fió- 
kot, ha még nem az. 

További tudnivalók pontokba szedve: 

1. Mielőtt elkezdjük a séma frissítését, 
Windows 2000-es natív működési szinten 
kell lennie a Windows 2000-tartományunk- 
nak, vagy Windows 2003-as natív szinten a 
Windows 2003-tartományunknak (a műkö- 
dési szintekről később még bőven lesz szó). 

2. Ha az adott gép lesz az első WSO8 DC az 
erdőben, akkor előzetesen az erdőt is prepa- 


rálni kell az Adprep/forestprep paranccsal. 





szítés, a tartomány és/ 


vagy az erdő felkészítése :vadprepdadprep /? 


a legtöbb esetben azért 


dprep (cmd? [option] 


upported (cmd2: 
forestPrep 


némi terhet is jelenthet 
(még ha általában éde- donainPrep 
set is). Ha másért nem, 

domainprep /gpprep 
akkor azért, mert ala- 
pos áttekintést és mér- 
legelést követel meg az 
üzemeltetőktől, mivel a 


sémafrissítés egyik kü- ggsséeetasákadjs 


nosSPWarning 


lönlegessége abban rej- 
lik, hogy visszafordítha- 
tatlan, visszavonhatat 
lan folyamat, azaz vég- 
telenül körültekintően 
kell eljárnunk a változ- 
tatásokkal, főképp nagyobb és/vagy bonyo- 
lultabb környezetben. A Windows Server 
2008 apropóján tehát az operációsrendszer 
frissítési tudnivalók után a sémafrissítésről is 
feltétlenül meg kell emlékeznünk. 
Köztudomású, hogy mielőtt egy új operá- 
ciós rendszert tartalmazó tartományvezérlőt 
akarunk telepíteni egy előző verziójú AD- 


környezetbe, a sémát mindig frissítenünk 


JANUÁR-FEBRUÁR 





he syuntax of the command is: 


Update forest information 
Must be run on the schema role master 


Update domain information 
Must be run on the infrastructure role master 
Must be run after /forestPrep is finished 


Update permissions on Group Policy Übjects in 
ctive Directory Domain Services and VOL 
Must be run on the infrastructure role master 

Must be run after /forestPrep is finished 


Update permissions on NDNC partitions to 

enable replication for Read-only Domain Controllers. 
Runs remotely and contacts a NDNC replica to update 
permissions. Must be run after /forestPrep is 
finished. Can be re-run at any time. You should run 
this in particular when you have DNS application 
partitions in your forest. 


adprep will suppress the Windows 2888 service 
pack 4 reguirement warning during /forestprep 


Return wssg-specific error codes 


adprep will suppress all output. May only be used 
with /wssg. 


Az új Adprep paraméterei és opciói 


Ekkor a séma frissítését a Schema Master 
egyedi szerepkörrel ellátott DC-n kell elvé- 
geznünk, ami annyira egyedi, hogy összesen 
egyetlenegy ilyen gépünk lehet csak az egész 
erdőben - ez az úgynevezett forest root DC. 

3. Ha ez a gép lesz az első WSO8 DC a tar 
tományban (de az erdő már elő van készítve), 
és a tartomány Windows 2003-as működési 


szinten van, akkor az Adprep /domainprep 


(mlEdil x 


parancsot kell használnunk az Infrastructure 
Master FSMO szerepkört birtokló DC-n a 
tartomány előkészítéséhez. Ha a tartomány 
esetleg még Windows 2000-es működési 
szinten van, akkor viszont az Adprep /do- 
mainprep /gpprep parancs lesz a nyerő, mi- 
vel ekkor a Group Policy-objektumok és a 
SYSVOLJogosultságok problémáját is ren- 
deznünk kell. 

4. Ha gond nélkül lemegy minden pa- 
rancs, és így az erdő és a tartomány prepa- 
rálása, akkor nem lesz rá szükségünk, de 
egyébként jó, ha tudjuk, hogy az Adprep de- 
bug naplófájlok helye megváltozott, immár 
a következő helyen találjuk őket: 9Yosystem- 
rootJovdebugvadprep. 

E rész végére került extra információ is, 
amellyel még nem találkozhattunk, akárhány 
éve ütjük-verjük a sémát. 

Az a speciális helyzet állt elő ugyanis, hogy 
a WSO8 egyik nagy dobásaként számon tar- 
tott teljesen új típusú tartományvezérlő, a 
RODC (Read-.Only DC) működik az erdő 
Windows Server 2003-es szintjén is (igaz, egy 
kisebb szépséghibával, lásd e cikk legvégén). 
Ha tehát a Windows 2003-as tartományunk- 
ban szeretnénk RODC-ket csatasorba állíta- 
ni, akkor van még egy teendőnk az Adprep- 
pel, mivel preparálnunk kell a Windows 
2003-as működési szinten lévő erdőt azért 
is, hogy a RODC replikálhassa a DNS-alkal 
mazáspartíciókat. Viszont ehhez nem kell a 
Schema Master gép, az erdő bármelyik tar- 
tományvezérlőjéről elindíthatjuk az Adprep 
/rodcprep parancsot, de ehhez is szükséges 
az Enterprise Admins csoporttagság. 

Ha úgy tervezzük, hogy a RODC-nk egy- 
ben GC (elobáliskatalógus-kiszolgáló) is lesz, 
akkor az erdő minden egyes tartományában 
kivétel nélkül futtatnunk kell az Adprep/ 
domainprep parancsot, akár van ezekben 
WsSOoS8 DC, akár nincs. Ennek a kritérium- 
nak az oka az, hogy így a RODC képes lesz 
replikálni a globális katalógus adatait min- 
den tartományból, és így - és csak így - teljes 
értékű GC-nek számít majd. 

Az első WSOS DC egy meglévő Windows 
2000/2003/2008-as tartományban semmi 
képpen nem lehet RODC, ezt a szerepet csak 
egy második WSO8 birtokolhatja, mivel az 
első ahhoz kell, hogy a RODC ezen keresz- 
tül érje el a tartományt, és be tudja indítani 
a speciális replikációt, a jelszószinkront és 


egyebeket. 
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A működési szintek 
Harmadik lépésben a szintén speciális műkö- 
dési szintekről lesz szó, mégpedig azért, mert 
az ezzel kapcsolatos teendők is minimum le- 
hetséges, de sok esetben kötelező elemei lesz- 
nek a WSO8 bevezetésének. A most követ 
kező áttekintéssel tehát ezen a terhen szeret 
nénk kicsit könnyíteni, 
sorba állítva a lehetséges 
forgatókönyveket. Persze, 


Domain name: 
azt is szeretném rögvest 


fenestra2 local 
megjegyezni, hogy ugyan 
a WSOS8 RIM bejelenté- 
sének már stabil, kitűzött 


dátuma van (2008. feb- 


ruár 27.), jelen pillanat 


Windows 2000 native 


ban még nem 100 szá- 
zalékosan tiszta minden 
körülmény, egy-két ap- 
róbb dologról 


esetleg 


mez 


Current domain functional level: 


Select an available domain functional level: 
Windows Server 2008 y 


After you raise the domain functional level, ít cannot be reversed. For more information 
on domain functional levels, click Help. 





A működési szint előléptetését követően a 
korábbi operációs rendszereket futtató tarto- 
mányvegérlőket nem lehet a tartományba be- 
léptetni. Ha például a tartomány működési 
szintjét előléptetjük a Windows Server 2003 
szintre, Windows 2000 Servert futtató kiszolgá- 
lókat tartományvezérlőként már nem lehet hoz 








még kiderülhet, hogy 
időközben megváltozott. 
Kötelességem szólni arról 
is, hogy a sémafrissítéshez hasonlóan a mű- 
ködési szintek változtatása is visszavonhatat 


lan folyamat, tehát csak óvatosan! 


Az alapfogalmak 
(Csak a "Windows 
2003-ra kihegyezve jöjjön egy kis összefog- 


tÖMÖTEN ÉS SÉNYEG 
laló, egy még erőteljesen nyomdaillatú, de 
remélhetőleg a jövőben sokak által alapo- 
san megforgatott könyvből, amelynek cíi- 
me: Rendszerfelügyelet rendszergazdáknak: 
http://tinyurl.com/2jgwdp. 

,A tartományok és erdők Windows Server 
2003 Active Directoryban bevezetett működési 
szintjeinek segítségével engedélyezhetők bizo- 
nyos tartományi és erdőszintű Active Directory 
szolgáltatások. A hálózati környezettől függően 
másféle beállítások állnak rendelkezésre a tar- 
tományok és az erdők különböző működési 
szintjein. A működési szint egyrészt meghatá- 
rozza a tartományban, illetve erdőben elérhető 
szolgáltatások körét, másrészt a működési szint 
emelésével régebbi tartományvezérlők már nem 
adhatók a tartományhoz. A tartományok mű- 
ködési szintjei a teljes tartományban, és csakis 
az adott tartományban elérhető szolgáltatáso- 
kat befolyásolják. A tartományokhoz négy mű- 
ködési szint áll rendelkezésre: Windows 2000 
— vegyes (mixed), Windows 2000 — natív, 
Windows Server 2003 — átmeneti (interim) és 


Windows Server 2003. 
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A WS08 alapértelmezett tartományi működési szintje a Windows 2000 natív 


záadni a tartományhoz. Természetesen tovább- 
ra is beléptethető a tartományba egy Windows 
2000 Server, bármiféle feladatot is elláthat, 
csak tartományvezérlő nem lehet többé. 

Az erdők működési szintjének beállításá- 
val az erdő összes tartományán engedélyezhe- 
tők szolgáltatások. Az erdőkhöz három mű- 
ködési szint áll rendelkezésre: Windows 2000, 
Windows Server 2003 — átmeneti (interim) 
és Windows Server 2003. Az erdő működé- 
si szintjének előléptetését követően, a korábbi 
operációs rendszereket futtató számítógépeket 
tartományvezérlőként nem lehet az erdőbe be- 
léptetni. Ha például az erdő működési szintjét 
előléptetjük a Windows Server 2003 szintre, 
Windows 2000 Server rendszert futtató tar- 
tományvezérlőket már nem lehet hozzáadni 
az erdőhöz. 

A működési szint emelése több előnnyel is 
jár, például így tehetjük lehetővé bizonyos erdő- 
vagy tartományszintű új szolgáltatások, megol- 
dások használatát (univerzális csoportok stb.), 
és az Windows Server 2003 R2 változat bizo- 
nyos szolgáltatásai is csak magasabb működési 
szinteken használhatók." 

Nos, annyi biztosan kiderülhet bárki szá- 
mára ebből az idézetből, hogy a WSO8 kap- 
csán is szét kell választanunk a témát két 
részre, a tartományok és az erdő szintjére. 
Először koncentráljunk a tartományok mű- 


ködési szintjével kapcsolatos okosságokra! 


WS08: tartományműködési szintek 

A legfontosabb: a WSO8 a mixed üzemmód 
kivételével a többi felállásban képes lesz tar- 
tományvezérlőként dolgozni. Iehát a WS08 
DC egy NI4 PDC-vel már semmiképp nem, 
viszont a Windows 2000/2003-as tartomány- 


vezérlőkkel biztosan egyet fog érteni. 


Windows 2000-es natív módú 
tartományok 
Tartományvezérlő 
WSOS. 
Berakhatunk tehát egy ilyen tartományba is 
WSO8 DC-ket, de a tökéletes együttműkö- 


déshez szükség lesz még némi plusz technikai 


lehet: as W2IKW RK, 


információra, amely azonban még nem köz- 

kincs, de nyilván hamarosan az lesz. A tisz- 

tán WSOS8-újdonságok (lásd a végén) viszont 

a tartománynak ebben az állapotában nem 

használhatók, hiszen az új technológiák alap- 

feltétele a natív WSO8-as tartományi üzem- 

mód. A W2Kss natív módú tartományok vi 

szont a következő pluszokat adhatják az előző 

(a mixed) módhoz képest: 

a Az univerzális csoportok biztonsági és ter- 
jesztési csoportokként is használhatók. 

a Csoportok általános egymásba ágyazható- 
sága. 

a Biztonsági és terjesztési csoportok közötti 
konverzió. 

a SID history: a felhasználó régi, más tar- 
tományban használt SIDJét tartalmazza, 
amelyre tipikusan egy migráció után lesz 


szükség. 


Windows Server 2003-as módú 

tartományok 

Tartományvezérlő lehet: W2K3, WSO8. 

Ebben az üzemmódban a Windows 2000 

DC-k már nem, a Windows Server 2003-ak 

viszont csont nélkül használhatók együtt 

a WSO8-as tartományvezérlőkkel. A jó pár 

WSO8-újdonság viszont szintén nem műkö- 

dik majd ilyen körülmények között. A W2K3 

natív módú tartományok például a követke- 

ző pluszlehetőségeket biztosítják az előző (a 

W2Ks natív) módhoz képest: 

a A Netdom.exewvel átnevezhetjük a tarto- 
mányvezérlőt. 

a A , Users" és a , Computers" tárolók (azaz 
nem OU) átirányítása. 

a Képes frissíteni a gépek, illetve a felhasz- 
nálók viszonylatában a LastLogonlime 


attribútumot és replikálni a LastLogon- 
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TimeStamp-et a tartományon belül (még 

ha kissé nehézkesen, azaz nem túlságosan 

nagy pontossággal is). 

an Az Authorization Manager a házirendjeit 
tárolhatja az AD-ban. 

a Rendelkezésre áll a Kerberos Secure 

Delegation az alkalmazások számára a 


Kerberos hitelesítés kikényszerítésére. 


Windows Server 2008-as módú 

tartományok 

Tartományvezérlő lehet: WS08. 

Ha már itt tartunk majd; akkor az azt fogja 

jelenteni, hogy csak WSO8 DC-iink vannak 

(vagy elszúrtuk, de nagyon). Ez a szint azért 

fontos, mert gyakorlatilag az összes nagyobb 

és fontosabb címtárszolgáltatási újdonság ek- 

kor érhető el csak teljes mellszélességgel. A 

WSO8-as módú tartományok tehát például (a 

lista nem teljes!) a következő extrákat adják 

az előző (a W2K3-as) módhoz képest. 

un DFS-R-replikáció a SYSVOL megosztás 
számára (kifejezetten kellemes dolog, hi 
szen ekkor bevethető a DFS-R részeként 
az RDC algoritmus, amivel könnyedén 
magas tömörítési hatásfokot is elérhetünk, 
már csak azért is, mert az RDC a különb- 
ségi replikációs módszert preferálja). 

n Kerberos AES 128/256-támogatás. 

nm Last Interactive Logon Information, amely 
megmutatja a felhasználó legutolsó sikeres 
interaktív belépésének időpontját, az eh- 
hez használt munkaállomást, illetve a si- 
kertelen belépések számát is (a hírek sze- 
rint elvileg az ismerős Acctinfo.dll integ- 
rálásáról van szó, bár nekem még eddig 
sehogy sem sikerült előcsalogatni ezeket az 
infókat a ADUC-ban). 

a Fine-grained password policies, azaz alter- 
natív jelszóházirend (eddig egy tartomány- 
ban maximum egy jelszóházirend kialakí- 
tására volt lehetőségünk, de ez változott), 
akár OU-ként különböző jelszóházirend- 
opciókkal. További, részletes infót erről a 
TechNet Magazin korábbi számában talá- 
lunk: http://tinyurl.com/2eo7sx. 

A tartományok után az erdők működési 
szintjének WSO8-as szintre emelésével foly- 
tatjuk. Mindenekelőtt visszanyúlunk az ala- 
pokhoz az előző alkalommal is emlegetett 
könyvből vett idézettel: 

, Az erdők működési szintjének beállításá- 
val az erdő összes tartományán engedélyezhe- 
tők szolgáltatások. Az erdőkhöz három mű- 
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ködési szint áll rendelkezésre: Windows 2000, 
Windows Server 2003 — átmeneti (interim) és 
Windows Server 2003. Az erdő működési szint- 
jének előléptetését követően, a korábbi operációs 
rendszereket futtató számítógépeket tartomány- 
vezérlőként nem lehet az erdőbe beléptetni. Ha 
például az erdő működési szintjét előléptetjük a 
Windows Server 2003 szintre, Windows 2000 
Server rendszert futtató tartományvezérlőket 
már nem lehet hozzáadni az erdőhöz." 
Összegzésként elmondható tehát, hogy 
sokkal óvatosabban kell bánnunk az erdő 


működési szintjének változtatásával. 


A W$08-as erdő működési szintjei 
A négyből Ő — a WSO8) három erdő műkö- 
dési szintje mellett használhatunk WSO8-as 
tartományvezérlő(ke)t. Nézzük át az idők kez- 
detétől, hogy mi minden pluszt lehetett ko- 
rábban elérni egy-egy erdő működési szintjé- 
nek emelésével. 

Windows 2000-es natív módú erdő. lar 
tományvezérlő lehet: W2K, W2K3, WSO8. 

Az akkor még újnak számító és előd nél 
küli címtárszolgáltatás összes alapértelmezett 
tulajdonságat használlhattuk. 

Windows 2003-as natív módú erdő. lar- 
tományvezérlő lehet: W2K3, WSO8. 

Néhány újdonság (természetesen nem az 
Összes): 

a Cross Forest Irust, azaz erdők közötti bi 
zalmi kapcsolat kialakítása, magyarul két 
erdő összekötése, például két cég összeolk 
vadásának apropóján. Kétirányú, tranzitív 


az erdők összes tartománya 


[mlEil x 


visszakaphatjuk a koszt is, tudniillik az in- 

aktiválás visszavonása, a deaktiválás is mű- 

ködik. 
a A RODC használata. 

Windows Server 2008-as módú erdő. 
Tartományvezérlő lehet: WS08. 

Kicsit megdöbbentő, de a tartományi szint 
számtalan újdonságával nagyjából el is lőttük 
a puskaport, azaz erdőszinten nincs semmi 
lyen extra újdonság. Egyetlen dolgot azért 
meg kell említeni, ami miatt valószínűleg 
érdemes is lesz megemelni az erdő működé- 
si szintjét, ha lehetséges. A dolog a RODC- 
val kapcsolatos, de messziről futunk neki. 
Néhány alkalmazásnál megszokott dolognak 
számít, hogy a címtárban tárol szenzitív ada- 
tokat (jelszavakat, jogosultságokat, titkosított 
külésökát stb 

Ezzel nincs is gond, sőt praktikusnak is 
tekinthetjük a módszert, a tartományvezér- 
lőkre amúgy is fokozottan oda kell figyelünk, 
és hát valóban ritkán tűnik el egy-egy DC a 
szerverszobából teremből. Viszont ha beke- 
rül majd a képbe egy-egy RODC - ismerve 
a tulajdonságait: csak olvasható, jelszavakat 
nem tárol, Server Core-ra is felmegy stb. 
- a telephely egy sötét sarkába lerakva, akkor 
azért kicsit mégis aggódhatunk. Egy címtár- 
példány ugyanis azért lesz azon a gépen is, 
szóval ha történetesen ellopják, azért kibá- 
nyászható lesz belőle ez-az. 

Nos, erre találta ki a Microsoft okosan az 
úgynevezett RODC Filtered Attribute Set 
(RODC FAS, korábban RO-PAS néven is fu- 





között, de nem az egyik er 
dőhöz ugyanígy kapcsolódó 
harmadik erdő felé. 


a Tartományátnevezés. 


Forest name: 


fenestra2 local 


a Link valued replication, az- 
az. tinomitott " replikáció, 
amely  sávszélesség-takaré- 

kos, és lehetővé teszi, hogy 

ne az adott elemet tartalma- 
zó egész tömb replikálód- 
jon, hanem csak az az elem, 


amely ténylegesen megvált 





Raise forest functional level 


Current forest functional level: 
Windows Server 2003 


Select an available forest functional level: 
Windows Server 2008 y 


After you raise the forest functional level, ít cannot be reversed. For more information on 
forest functional level, click Help. 





tozott. 
a Sémaelemek  inaktiválása, 
azaz olyan osztályok és attribútumok kivo- 
nása a forgalomból, amelyek sérültek vagy 
már nem szükségesek. A törlés nem járha- 
tó út továbbra sem, de legalább a takarítás 


megoldható, sőt nagy szükség esetén akár 


Megtörténik mindjárt. . . 


tott) használatának lehetőségét, ami azt jelen- 
ti, hogy a WSO8 Schema Master DC-n pél 
dául az Idfide-vel vagy az ADSIEdittel meg- 
növelhetjük az adott attribútum tulajdon- 


ságai között a searchFlags értéket (például 


ya 
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O0-ról 640-re - CONFIDENTIAL/ 
RODC FILTERELDL, lásd a képet, 


bár ott még hexában van). Így aztán 


CN-Employee-Number Properties 


Attribute Editor ! Security 


Attnibutes: 


ha a tartományvezérlő beleakad eb- 
be az értékbe, akkor ezt az attribútu- 
mot nem fogja replikálni a: RODC 
kérésére. Mármint a WSO8 GC 
DC-k, merthogy egy WSO03 GC DC 


továbbra is megengedő lesz (kipró- 





báltam ezt is, hiába piszkáljuk meg 
az említett flaget a WSO3 Schema 
Masteren, nem érti), és csont nél 
kül hagyja magát megerőszakolni. 


Ha viszont az erdőnkben már nincs 





és nem is lehet effajta , régi" DC, 
akkor a problémát - kicsit közvetve 
ugyan, de - letudtuk. 

Söt, a WSO8-ban már gyárilag 
meg van jelölve ily módon egy pár 
attribútum, elsősorban a Credential 
Roaming (azaz ha több gépen be- 
jelentkezve akarunk azonos tanúsítványt 
és kulcskészletet használni) és a BitLocker 
miatt, konkrétan ezek: 

n ms-PKIDPAPIMasterkeys; 
n ms-PKLAccountCredentials; 


tribute 
olPropertyMetaData 
biupToDateVector 
dsFrom 

bsTo 

vision 
hemaFlagsEx 
IhemalDGUID 


low InAdvancedVee... 
IbRefs 

stemFlags 

stemOnly 


$NChanged 


Value 


AttID Ver Loc.USN 
not set? 
not set: 
cnot set: 
not set; 
not set: 
agdf 73ef-c5ea-1 1d1-bbcb-0080c76670c0 


Orag.DSA 


TRUE 
not set? 
0x0 -( ) 
FALSE 
not set: 
65598 


"I 





Az általam variált Employee-Number attribútumon szépen látszik a 
változás 


a. ms-PKI-Roamingl imeStamp; 
a ms-FVE-KeyPackage; 

a ms-FVE-RecoveryGuid; 

a ms-FVE-RecoveryÍ Information; 


a ms-FVE-RecoveryPassword; 
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a ms-FVE-VolumeGuid; 
na  ms-I PM-Ownerlnformation. 

Annyi még lényeges, hogy a jelszavak rep- 
likálásával ellentétben itt nincs választási le- 
hetőség egyesével. Akárhány RODC-vel ren- 
delkezünk, a megjelölt attribútumok egyikre 
sem fognak replikálódni. Vagy mindre fog- 
nak, ha nem jelöljük meg. 

Ha már itt tartunk, azért említsük meg, 
hogy a FAS mellett/helyett van még egy 
lehetőségünk, ez pedig a védendő attri 
bútum searchFlags értékének feljavítása a 
, CONFIDENTIAL" szintre (ennek 128 a 
decimális értéke, ami az előző esetben ugye 
automatikusan benne van a 640-ben, látszik 
is az előző képen). Ezt a WSO3 SPI1 óta lehet 
séges művelni, van is hozzá egy fárasztóan 
bonyolult KB cikk ((2922836). Gyakorlatilag 
e változtatás az Authenticated Users csoport 
Read jogát veszi le (ergo egy akármilyen jött 
ment RODCiét is), csakhogy - állítólag - az 
a gond lehet ezzel, hogy az említett alkalma- 
zások esetleg nem veszik majd jónéven. 

Gál Tamás 
(v-tagal(0 microsoft.com) 
Microsoft Magyarország 
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CNN NR 


Süss FEL, NAPI! 


A Microsoft kiváló biztonsági szakemberétől, Steve Riley-től 


származik az a hasonlat, hogy mostanáig a vállalati hálózatok egy 


lakóparkra hasonlítottak: kerítés, sorompó és biztonsági őr kívül, 


nyitott ablakok és aitók belül, és grillparti a gyepen. 


boldog békeidők elmúltak: a napjainkban elérhető fenyegetések közvetlenül a házacs- 
kákra támadnak, nem elég többé a távoli kerítés: amíg a kerti grillt sütögetjük, valakik 
szétlopják a tulajdonunkat bent a házban. Vasrácsot kell szerelni minden ajtóra és ab- 

lakra. Erre a feladatra való a Network Access Protection. 
A Vistában és a Windows Server 2008-ban megjelenő technológia nem előzmények nélküli. 
Már a Windows Server 2003/XP felállásban is használhattunk hasonló szolgáltatást a VPN- 


kapcsolódás ellenőrzésére. Úgy hívják: VPN-karantén. Igaz, kevesen használják, mert egyrészt 


8 a 





RADIUS messages 













HRA 
Health reguirement 
Remediation server 
server 
me System health 
system reguirerment 
Hajih gueries 
updates 
DHCP server 
NAP client NAP health 
policy server 
E (NPS) 
VPN server 


áz 








IEEE 802.1X network 
access devices 











1. ábra. A NAP belül mindig RADIUS-t használ 


bonyolult, másrészt a sok , HTIP over..." protokoll miatt a VPN-használat visszaszorulóban 
van, ennek ellenére érdemes áttekinteni a technológia elvi alapjait, mert a karantén és a NAP 
ugyanaz, csak picit más. (Persze valójában egyáltalán nem ugyanaz, a kettő vígan eléldegél egy- 
más mellett, egymással párhuzamosan. Kiegészítik egymást. Viszont VPN-keretben jobban át 
tekinthető a történet. Ígérem, rövid leszek.) 

Mi is a VPN? Egy meghosszabbított UT P-kábel, amely a céges hálózattól vezet az otthoni 
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szutykos gépemig. Ne dugjuk homokba a fe- 
jünket: az otthoni pécék, amelyeken a gyerek 
játszik, és vírusokat tenyészt, a VPN-kapcsolat 
révén közvetlen ICP-kapcsolatba kerülnek a 
vállalati hálózattal, hogy ott sikeresen szétszé- 
ledhessenek a különböző gusztustalan férgek. 
Ez ellen természetesen van védekezés: mi len- 
ne, ha minden otthoni számítógép fitt lenne a 
kibocsátott frissítések területén, esetleg lenne 
rajta egy naprakész víruskergető, bezárt tűzfal 
stb. Szép kis kívánságlista, de hogyan biztosít 
ható, hogy ez a Józsi bácsiék pécéjén valóban 
így legyen? Sehogy. A megoldás kulcsa, hogy 
a határállomáson (a VPN-kiszolgálón) alapos 
ellenőrzést hajtunk végre, és ami nem felel 
meg nekünk, azt nem engedjük be. 

Nos, a NAP ugyanez, csak azzal a különb- 
séggel, hogy a lakóparkon belüli személye- 
ket vizsgáljuk: kijöhetnek-e a gyepre a közös 
grillpartira, vagy leteperte őket valami beteg- 
ség, úgyhogy inkább maradjanak szobafog- 
ságban. Az érdekes az, és ennyiben minden 
életből vett hasonlat sántít, hogy mind a ka- 
rantén, mind pedig a NAP esetében a vizs- 
gálatot maga a célszemély hajtja végre önma- 
gán, és dönt arról, hogy közösségbe mehete. 
A központi doktor Bacsircsak a vizsgalat szaz 
bályaiért és azok betartásáért felelős, magáért 
a vizsgálatért nem. 

Tehát ez egy kliens-szerver architektúrá- 


ban működő szolgáltatás. 


Kényszerek (enforcement) 

A NAP számos trükköt tartalmaz az egészség- 
telen számítógépek távol tartására. Mindegyik- 
ben közös viszont a tyúk-tojás paradoxon, 


mert mindaddig nem tudjuk, hogy egy szá- 


yt 


ed 
a 
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mítógéppel kommunikálhatunk-e, amíg meg 
nem beszéltük vele, hogy egészséges-e. Ehhez 
meg nyilván hálózati kapcsolat kell. A megol 
dás a szűkített hálózati szolgáltatásban rejlik. 
Attól függően, hogy pontosan melyik korláto- 
zási módszert használjuk a betegek ellen, más 
és más módon adhatunk nekik a vizsgálat 
idejére valamilyen korlátozott kapcsolatot. A 


NAP külső gyártók által is bővíthető, jelenleg 


ked ratiLd djher isa a 


VPN Enforcement. Itt kellene megma- 
gyaráznom a NAP és a VPN-karantén közti 
különbséget, mert úgy tűnik, mind a kettő 
ugyanazt csinálja. Igen, de másképp. A ko- 
rábbi (ősi) módszer, a VPN-karantén alapve- 
tően a rendszergazda kezébe adja, hogy mit 
akar ellenőrizni, és mit tart az egészség biztos 
jelének. Ehhez egy furfangos batch-fájlt kell 
készíteni, amihez nem minden földi halandó- 


nak van türelme - nekem 


sincs. A NAPféle VPN. 
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megszorítás viszont már 
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7 TA RADIUS Clients and Servers 
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Getting Started 
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7 [E Polices 
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KA Network Policies 
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Ad Remediation Server Grour 
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Standard Configuration 














Network Access Protection (NAP) 
When you corfigure NPS as a NAP policy server, you create health policies that allow NPS to validate the 

configuration of NAP-capable client computers before they connect to your network . Clients that are not compliant 
with health policy can be placed on a restricted network and automatically updated to bring them into compliance. 


EJ Corfigure NAP 


Advanced Configuration 





Network Policy Server (NP5S) allows you to create and enforce organization-wide network access policies for 
st authentication, and 


connection reguest authorization. 


Select a scenario configuration from the list and then click the link below to open the scenario wizard. 
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az XP SP2-ben megjelent 
biztonsági központ álla- 
b potjelentésére épít, azaz 
az egészségügyi vizsgálat 
teljesen magától megtör- 
ténik, nem kell értékes 
órákat áldoznunk arra, 
hogy bugos batchfájlok- 


kal kísérletezzünk. Ha va- 





2. ábra. Kezdjük el konfigurálni a NAP-ot! 


a következő megszorítási módszerek érhetők 
el: IPSec, 802.1x, VPN és DHCP. 

IPSec Enforcement. Az IPSecet már régen 
nemcsak titkosításra használjuk, hanem ez az 
eszköze a nagyképűen Domain Isolationnek 
nevezett eljárásnak, ami lehetővé teszi, hogy 
a hálózaton jelen lévő számítógépeknek csak 
egy bizonyos köre tudjon kommunikálni egy- 
mással. Ez a korlátozás tehát viszonylag egy- 
szerű, mert más IPSecszabályokat alkotunk 
az egészséges, és mást a beteg ügyfeleknek. Az 
egészségesek mindent vagy sokkal több szol 
gáltatást elérhetnek, mint a betegek. 

802.1x Enforcement. A 802.1x szabvány 
mind vezetékes, mind vezetéknélküli hálóza- 
ton lehetővé teszi, hogy csak azonosított (új- 
magyarul: autentikált) eszközök léphessenek 
fel a hálózatra. Ez mind jelszóval, mind ta- 
núsítvánnyal működik, az azonosítást pedig 
egy központi címtárra bízhatjuk. (Így lehet 
elérni, hogy például egy adott switchre csak 
olyan gép csatlakozhasson, amelyik tagja egy 
adott Active Directory-tartománynak.) Ez a 
megszorítás a NAP alatt a következőt tudja: 
a hálózati csatlakozási ponton valami mint 
mális hozzáférést engedünk mindenkinek (a 
betegeknek is), hogy például legalább beje- 
lentkezni tudjanak, a NAP viszont nem enge- 
di bejelentkezni a betegeket. A végeredmény, 
hogy a betegek már a switch vagy a WiFi 


Access Point szintjén kiszűrődnek. 


ye 


lakinek mégis szüksége 

van a teljes szabadságra, 

a NAP-pal párhuzamosan használhatja az ősi 

karantént is, és olyan scriptet rittyent, ami 
lyet csak akar. 

DHCP Enforcement. Itt már fogós kér 

dés a védelem, mert egy számítógépnek vagy 

adunk IP-címet, vagy nem. Mit lehet ezen kor- 


látozni? Az opciókat! Például a be- 


CNN Re 


lyet márciusban jelent be a Microsoft, ügyfél 
ként pedig a Vista, valamint a Windows XP 
SP3 áll rendelkezésre. Az összes többi operá- 
ciós rendszer csak az árnyékban mozoghat, 
rájuk sohasem süt le a NAP, és ha csak vala- 
mi kötelező érvényű házirendnek nem kell 
engedelmeskednünk, nem engedjük be őket 
a NAP-pal védett hálózatba. 

A NAP maga is sokszereplős. Emeljünk ki 
két fontos kiszolgálószerepet! 

A NAP-xrendszer központjában a NAP 
Health Policy Server áll, amit a dokumen- 
tációkban NPS rövidítéssel illetnek. Ez fog- 
lalkozik a kliensekről befutó egészségügyi zá- 
rójelentések kiértékelésével; olyan Windows 
Server 2008 kiszolgáló, amelyen az NPS-szol 
gáltatás fut. Maga az NPS egyébként a ko- 
rábbi IAS-t (Internet Authentication Server) 
váltja fel, tehát RADIUS-kiszolgáló és VPN- 
házirendi központ is egyben. Néha úgy is 
hívják, hogy egy AAA, azaz Authentication, 
Authorization és Accounting szerver. 

Ha IPSeckel szeretnénk NAP-ozni (pél 
dául mert buta a switchünk), szükségünk lesz 
egy Health Registration Authorityra (HRA), 
amely közvetlen kapcsolatban áll az ügy- 
félszámítógépekkel, és átveszi azok kórházi 
zárójelentéseit, és továbbítja az előbb emlí 
tett NPS-nek. Ezen a kiszolgálón Windows 





tegek nem kapnak alapértelmezett 
átjárót. Emellett aki beteg, annak 
a. Subnet Maskja 255.255.253.1295. 
így csakis önmagával képes kom- 
(egygépes 
Nem ártana azonban, hogy ha a 


munikálni subnet). 
hamarosan bővebben is kifejtett 
patikaszervereket el tudná érni, 
ezért kap egy marék DHCP 249- 

es (Classless Static Route) opciót, vu 





ezáltal az ő rút táblácskájába beke- 





Configure NAP 


Network connection 
Select the network 


Additional reguirements-: 
o You must perform additional actions to setup NAP. View additional NAP reguirements by cicking on the 
link below. 


xi 


E Select Network Connection Method For Use with NAP 
, 


method: 


connection method that you want to deploy on your network for NAP-capable cient 
cortotlome: Created policies will work. with this network connection type only. To create policies for additional 
network connection methods, you can run the wizard again. 





IPsec with Health Registration Authority (HRA) Ni 


Policy name 
Ta rátát ten also ds BAL LÉ ÉS sső se OG TS ska ed sál ág ák You can use the 
default text or modffy it. 


NAP IPsec with HRA 





Additional Reguirements 





rül az a néhány bejegyzés, amely- 
nek segítségével el tudja érni azo- 
kat az erőforrásokat, amelyek a gyógyulásá- 
hoz szükségesek (beutalókat kap). Hozzá kell 
tennünk, hogy a DHCP-kényszerzubbonyt 
egy Administrator bármikor leveti magáról. 


Hallottunk már statikus IPcímekről? 


Szereplők 

Elérkeztünk a stáblistához. Lássuk, kik vesz- 
nek részt ebben a játékban? Az operációs 
rendszerek oldaláról három szereplőnk van: 


kiszolgálóként a Windows Server 2008, ame- 


3. ábra. Mivel biztosítsuk az izolációt? 


Server 2008 és IIS fut. [de kapcsolódnak be 
a NAP-ügyfelek HTTP- vagy HITPS-proto- 
koll segítségével, megmutatják a zárójelen- 
tésüket, és ha a HRA egészségesnek találja 
őket, visszaad egy Health Certificate-et, ami 
lehetővé teszi majd a megfelelő IPSec-házi- 
rend használatát. Iehát valahol a horizonton 
látszódnia kell egy Certificate Servernek is... 

Ha nem IPSecceet használunk, akkor az 
egyes NAP 


Enforcement Pointok látják el a védelmet a 


szolgáltatásoknak megfelelő 


Microsoft TechNet 
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korlátozott vagy teljes hozzáférés megadásá- 
val. Ilyen lehet például a DHCP vagy a VPN- 
kiszolgáló, a 802.1x-nek megfelelő switch 
vagy a WiFi Access Point. Ezek mindegyike 
közös abban, hogy RADIUS-szal kommu- 
nikálnak az NPS felé. A switch és az Access 
Point gyárilag képes erre - vagy ha nem, ku- 
kába velük. A DHCP és az RRAS csak akkor, 
ha feltelepítjük rá a RADIUS-klienst. Most 
jön a csavar: ezeken a gépeken tehát futnia 
kell az előbb említett NPS-szolgáltatásnak, 
de csak azért, mert abban van megvalósítva 
a RADIUS-protokoll! De ettől ezek nem vál 
nak NPS-szerverré! 

Remediation Servers: ezek azok a kiszolgá- 
lók, amelyeket mindenki, tehát a betegek is 
elérhetnek. Patikák. Ezekre érdemes feltenni 
azokat a frissítéseket, ami a gyógyulásukat 
hozhatja, hogy ha véletlenül lebetegedtek, le- 
gyen hova fordulniuk orvosságért. 

Health Reguirement Servers: ezekkel egy 
darabig nem fogunk találkozni, külső gyár- 
tók által létrehozott egyéb egészségügyi köz- 
pontok, amelyek további ellenőrzési lehetősé- 
geket adnak a NAP-rendszernek. Ilyen lehet 
például egy központi víruskergető-adatbázis, 
amelyik ,sugározza" a megfelelőségi szem- 
DORtOKkat. 

Ezeken felül vannak a védendő objektu- 
mok, a hálózatok és hálózati eszközök. Az I. 
ábra remekül összefoglalja a különböző NAP- 
esetek kommunikációs útvonalait. 

Érdemes megfigyelni, hogy bár az ügyfelek 
sokféle úton-módon, többféle protokollal (és 
autentikációs módszerrel) próbálkozhatnak 
bejutni a hálózatba, a NAP:kommunikáció az 
NPS felé mindig RADIUS! Egyébként nem 
kell ennyi vasat vásárolni: mindegyik NA P- 


szerepkör felpakolható ugyanarra a gépre. 


A NAP kezelése 

Kezdjünk el dolgozni a NAP-pal, indítsuk el 
a Network Policy Servert a rendszergazdai 
eszközök közül! A 2. ábra a NAP kezelőfelü- 
letét mutatja Windows Server 2008 kiszolgá- 
lón. Megfigyelhető, hogy magában foglalja 
a teljes RADIUS- protokollt is. Láthatjuk a 
Remediaton Server Group-ot, a patikákat is. 
Ha valaki az RRAS-házirendeket keresi, azo- 
kat is megtalálja a PoliciesWNetwork Policies 
mappában. A főablakban egy varázsló fogad 
bennünket, amely előzékenyen a NAP-va- 


rázslatot kínálja fel (a másik két varázsló a 


RADIUS-protokollt állítja be). 
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Menjünk végig az úton! Az első lépésben 
nevet kell adnunk a NAPházirendnek, és ki 
kell választanunk a felhasználandó korláto- 
zási módszert. Én most az IPSeces ágon me- 
gyek végig, mert ez az egyetlen, amelyik helyi 
hálózaton működik, nem igényel speciális 
hardvert, és meghekkelhetetlen. (A 802.Ix 
hez megfelelő switch kell, a DHCP pedig elég 
könnyen megkerülhető. A VPN pedig VPN.) 


CCT AS NÉ 


A 
sa 


szerárusítás a patikákban. Az összefoglaló 
képernyőn lehetőségünk van a teljes varázs- 
lat dokumentálására (HIML formátumban), 
hogy később is tudjuk, mit tettünk. A varázs- 
lat eredménye két Network Policy: egy az 
egészségeseknek (teljes hozzáférés), egy pe- 
dig a betegeknek (patika only). Ezzel a dolog 
könnyebbik részével meg is volnánk. Most 
jön a neheze: a HRA elkészítése, IIS-estül, 


Certificate Serverestül, valamint 





Configure NAP 


E Define NAP Health Policy 
, 


enforce with this health policy. 


[9 Enable autoremediation of client computers 
compliant with health pokcy can obtain software updates from remediation 


full network access until they are 











F selected, NAP-capable dient computers that are denied full access to the network because they are not 
servers. 


F not selected, noncompliant NAP capable client computers are not automatically uupdated and cannot gain 
manually updated. 


2 — az ügyfélszámítógépeken a meg- 
felelő NAP-ügynök bekapcsolása 
Group Poliéyval 


The installed System Health Validators are listed below. Select only the System Health Validators that you want to 


A munkaállomások 
beállítása 

A munkaállomásokon . található 
NAP-ügynököket akár egyesével is 
be lehet kapcsolgatni a Vistában 
már megtalálható NAP-ügyfélkon- 
figurátor MMC-konzollal. Ami 





4. ábra. Mi ellenőrizze a kliensek egészségét? 


Amint kiválasztjuk a varázsló első lépésében 
az IPSeckorlátozást, megjelenik egy figyel 
meztető ikon, hogy tudassa velünk: a varázslat 
után még rengeteg teendőnk lesz: Certificate 
Services, Group Policy stb. (3. ábra). 

Ezt követően be kell állítanunk a még 
fel sem telepített HRA-kiszolgálókat mint 
RADIUS-ügyfeleket. Emlékezzünk: ezek a 
jószágok állítják ki az egészségességet bizo- 
nyító tanúsítványt. Én egy gépen szeretném 
futtatni a NPS-HRA párost, ezért egy Next 
tel továbbmegyek. A követke- 


kor betöltjük ezt a konzolt, rákér- 

dez, hogy nincs-e a birtokunkban 
konfigurációs fájl, amivel egycsapásra elin- 
tézhető az egész beállítás. Kezdetben nincs, 
de ha már egy gépen megcsináltuk, mint pél 
dául ezen a magyar nyelvű Vistán itt (5. áb- 
ra), akkor a konzolból ki tudjuk exportálni a 
beállításokat, és a következő gépen már gyor- 
san végzünk az importtal. 

Egyébként ezeket az ügynököket nemigen 
kell és lehet finomhangolni. Kikapcs-bekapcs, 
és nagyjából ennyi. Ezenkívül be lehet állíta- 
ni egy címből, egy feliratból és egy képből álló 





ző lépésben lehet kiválasztani 
é5]13EHEE 


I Kezelőpultgyökér 


az érintett ügyfélszámítógépe- 
ket, ahol szintén továbsiklok 
egy Nexttel (lés a képernyő- 
képet sem vágom be ide), így 
minden számítógépre érvé- 
nyes lesz, még a tartományon 
kívüliekre is. Az a jó! 

Ezután következik a Health 








Validatorok kiválasztása. Egy 


[dá Konzol - [Kezelőpultgyökén NAP-ügyfél konfigurációjalkHelyi számítógépjNKényszerítési ügyfelek) 
IA Fájl Művelet Nézet Kedvencek Ablak Súgó 





a KÉ) NAP-ügyfél konfigurációja 
(2 Kényszerítési ügyfelek 
1 Felhasználói felület beál 
TI Állapotjegyzői beállításc 






Műveletek 
Kényszerítési ügyfelek 4 
Nézet ; 


Kényszerítési ügyfelek 






Név Állapai 


B OHCP-karanténkényezerítési ügyfél Letitva 
B, Tévelérés karantérkényszerílési ügyfele. Letilve 
B IPSectuggő enttás 7 
I, TS-átjáró karanténkényezeritési ügyfele . Letitva 
BEL FAPkeranténkényszer tési ügyléd Ledlva 





Új ablak innen 





Azonosító: 793619 
Név: IPSac függő enttás 
lekés Hálózatvédelem kényszerítése az IPSec alapján 
Veornó: 1.0 
Szálüó. Microsolt Corporation 
, 11 Alapot: Engodélyezve 


BZ, IPSecfügyő erditás 








alap . Windows-rendszerben 
a Windows Security Health 
Validator érhető el csupán: az ügyfélgépeken 
futó Security Center által nyújtott adatok 
fogják adni az egészségügyi információkat: 
van-e Defender telepítve, hogy állunk a hot 
fixekkel, elavulte a víruskereső. 

Ezt már megmutatom (4. ábra), mert itt 


lehet beállítani azt is, hogy legyen-e gyógy- 


5. ábra. Több kényszerítési ügynökünk is működhet párhuzamosan 


figyelmeztető üzenetet a felhasználónak, hogy 

tudja, ha a NAP miatt (a gépének egészségi ál 

lapota miatt) nem ér el valamit a hálózaton. 
Ugyanezt megtehetjük Group Policyból is. 

Fóti Marcell 

MCSE, MCT, MVP, MZ/X 

(marcellfrconetacademia. net) 
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A HARKÁLY ÉS 


A HANGYÁSZ 


Ha az a feladat, hogy a hangyát ki kell 


enni a fa kérge alól, arra jó a harkály. 


Ha a bogarat az odvas tából kell kirágni, 


rögtön hangyászért kiáltunk. Nem lehetne 


összepárosítani a kettőt? Talán, de addig 


is házasítsunk össze két másik fajt, amelyek 


talán nem is olyan idegenek egymástól! 


Legyen, mondiuk, a Failover Cluster és 


a virtualizáció. 


ecember közepe óta letölthető a Windows Server 2008 RC1 x64-Hyper-V kiegészítéssel. 


A számtalan újdonság közül kettő ragadja meg első látásra a rendszerintegrátor figyel 


mét: a Hyper-V virtualizáció és az arculatában és belvilágában is jelentős változtatáso- 


kon átesett fürtszolgáltatás. Mind a kettő izgalmas, és a gyakorlatban egyre inkább előtérbe ke- 


rülő megoldást kínál, már magában is: a clustering megvalósításakor manapság már nem (fel 


tétlenül) kell a jellemzően szűkös költségvetésbe méregdrága Fibre Channelinfrastruktúrát is 


beleerőltetnünk - az iSCSI a gyors hálózatokkal vállvetve hódít teret a failover clusternek is -, 


a virtualizáció pedig - függetlenül attól, hogy melyik típussal van dolgunk - tagadhatatlanul 


csábító előnyökkel jár. Gyors helyreállítások, migrációk és gazdaságos hardverkihasználtság, 


hogy csak a legvastagabban szedett címszavakat említsük. 


Mi sül ki kettejük házasságából? 

Gondoljunk csak bele, a clusterbe szerve- 
zett szolgáltatások ,ősidők" óta mint vir- 
tuális szerverek vannak jelen a hálózaton. 
Objektumokkal dolgoznak, amelyeken belül 
az elérhetőséget és az érdemi tartalmat kép- 
viselő resource-ok együttesen képeznek egy 
halmazt, a groupot. Ha pedig ez a group 
egyszer rá lett bízva a clusterre, az bizony an- 


nak létéért, életben tartásáért és cluster-aware 
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EZT LETE a rá íré at] 


in Select Service or Application 
! 


Before You Begin 


Select Service or 
Application 


Select Virtual Machine 


Select the service or application that you want to corfigure for hig 





CA Generic Application 

Éz] Generic Script 
a Generic Service 

€7 Intemet Storage Name Service ú5NS) Server 

ES Message aueuing 

EZOther Server 

Ésa Print Server 


ú Virtual Machine 








d WINS Server 





1. kép. A virtvalizáció a CÍuster applikációs varázslójában 


— Xx 
S 


applikáció esetén egészséges működéséért is 
a körme szakadtáig ragaszkodni fog. A clus- 
ternek számtalan ötlete van arra, hogy a leg- 
váratlanabb esetekben is elvégezze feladatát. 
A Windowsba integrált alapszolgáltatások és 
a , nagy, komoly kiszolgáló" szerepkörű alkal 
mazások jó részét ugyanúgy támogathatja, 
mint az általunk a rendszerbe illesztett scrip- 
tet vagy egy olyan szolgáltatást, ami még éle- 
tében nem is hallott fürtözésről. 

Miért is maradna ki ebből a körből a 
Hyper-V? Hát, nagyon úgy néz ki, hogy esze 
ágában sincs kimaradni (Il. kép)! 

Hol igényli a virtualizáció a fürtszolgálta- 
tással való kapcsolatot? Iermészetesen a ren- 
delkezésre állásban. A virtualizáció magában 
nem kínál magasabb rendelkezésre állást, 
mint amennyit Murphy szán neki, hiszen 
akár a hardvert, akár a gazda-operációsrend- 
szert bármikor elütheti a villamos, a vendég- 
operációsrendszer vagy a benne futó alkal 
mazás is csak egyszer lépjen le figyelmetlenül 
a járdáról... és kész a baj. Ha sóhajtozunk egy 
integrált megoldásra áhítozva, hát tessék! 
Több modell is rendelkezésre áll, csak győz- 


zünk választani! 


Guest Cluster — egy gépen 

Legyen ez inkább csak játékszer - remek le- 
hetőség egy fejlesztőnek, aki inkább az al 
kalmazásának fürtben való viselkedését vizs- 
gálja, vagy tesztplatform a cluster témában 
szárnyait bontogató olyan rendszergazdának, 
akit nem dobnak meg egy teljes kiépítettsé- 
gű bladerendszerrel, hogy tesztelgessen csak, 
okosodjék bátran. Viszont akár komolyan is 
vehetjük, ha kizárólag a clusterbe szervezett 
alkalmazás rendelkezésre állását vizsgáljuk: a 
szolgáltatás védve van... 

Hogy is néz ki egy ilyen , Egygépes Guest 
Cluster"? 

Először is szükségünk lesz egy jó sok me- 
móriával rendelkező gépre. A gazdarend- 
szer és a virtualizációs környezet telepítése 
után létre kell hozni minimum 3 virtualizált 
vendég-operációsrendszert. Kettőből lesz a 
cluster két nodeja, egyet megtartunk tar- 
tományvezérlőnek. (Lehet akár a 2 node 
bármelyike is DC, vagy akár mindkettő, de 
egészségesebb, ha külön DC-t tervezünk be.) 
A megosztott diszkalrendszer lehet többfé- 
le: ISCSI, amit a tartományvezérlőre telepí 


tett targetkomponenssel valósíthatunk meg, 
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vagy a komolyabb virtualizációs környezetek 
által emulált , shared parallel scsi" (vigyázat, 
a Windows Server 2008 Failover Cluster ezt 
már nem támogatja!) 

Gyors telepítés, teszt, tapsvihar. Ha ISCSL 
val futottunk neki, és a gazdagépen maradt 
még szabad kapacitás, akár 3 vagy többtagú 


fürtöt is létre lehet hozni. 


Guest Cluster — több gépen 

Ez a megoldás már éles környezetben is meg- 
valósítható, sőt! Megvalósítandó minden 
olyan esetben, ahol rendelkezésre áll két vagy 


több olyan szervergép, amelyekből, illetve 


ver bázisú iSCSImegoldása, mint például 
egy HP MSA 1510i, akkor még a target meg- 
valósításához sem kell gép, de szegény ember 


vízzel főz... 


A Host Cluster 


Igen, lassacskán a cikk témájánál vagyunk, 
hiszen pont ilyet építhetünk a még csak tesz- 
telésre való Hyper-V és a Failover Cluster se- 
gítségével a Windows Server 2008-ban! Mi is 
ez a Host Cluster? 

Gondolkodjunk kicsit máshogy, mint az 
előző modellek esetében: ne a fürtöt illesszük 


a virtualizációba, hanem... him... csináljuk 























HA Guest, 
Windows Server 2008 x64 


Guest, 
Windows Server 2008 x64 






Windows Server 2008 
x64 Enterprise; Hyper-V; 
MS ISCSI lnitiator 











Guest, 
Windows Server 2008 x64 









Windows Server 2008 
x64 Enterprise; Hyper-V 
MS ISCSI lnitiator 





Windows Storage Server 
2003 R2 4 ISCSI Target 
AD DC; ISNS 








2. kép. Ebben a környezetben vizsgálódunk 


a rajtuk futó gazda-operációsrendszerekből 
nem akarunk clustert építeni, de az egyes 
node-okon futó vendégekből igen - tehát a 
cluster nodejai az egyes fizikai gépeken vir- 
tualizált vendégek. Ebben az esetben az iSCSI 
már magától értetődő, ha a megosztott disz- 
kek megvalósításán gondolkodunk. Hogyan 
is lehetne mondjuk Fibre Channeladaptert 
illeszteni egy guestbe? Hát sajnos... sehogy. 

Mi kell a több fizikai gépes Guest Cluster 
elkészítéséhez? 

Vegyünk három gépet. Kettőből egymás- 
tól függetlenül lesz gazdagép a virtualizációs 
környezetben, egyet megtartunk iSCSI target 
portálnak és tartományvezérlőnek. A dedi- 
kált DC létjogosultsága ugyanúgy magyaráz- 
ható, ahogy az egygépes esetben: jobb, ha azt 
nem keverjük bele a játékba. Miért nem a 
gazdagépek akár mindegyike DC? Lehetnek 
azok is, de az iSCSI target azért legyen külön. 
A kötekedőknek: akinek van a polcon hard- 


JANUÁR-FEBRUÁR 


fordítva! Eddig mindkét guest cluster modell 
esetén úgy kezdtük, hogy a gazdagépre virtu- 
alizációs környezetet, majd abba vendégeket 
telepítettünk, ezekből lettek a cluster node- 
jai. Most dőljünk hátra és fantáziáljunk! 
Gondolatban próbáljuk meg a clusterbe ilb 
leszteni a virtuális masinát és próbáljuk meg, 
hogy működik-e úgy, mint bármelyik másik 
jól nevelt és clusterbe szervezett szolgáltatás! 
Mozgassuk át a cluster egyik nodejáról a má- 
sikra... és vissza! Ez lenne a Host Cluster? Ez 


bizony. Hogy is néz ki ez a gyakorlatban? 


Építsünk Host Clustert! 


Addíg, amíg az előző modelleket javarészt 
egy Microsoft Virtual PC-vel is meg lehet 
valósítani, a következő teszt már szigorúan 
Hyperv- és Windows Server 2008-specifikus 
környezetet kíván. Két olyan gépet legalább, 
amelyek megfelelnek a kritériumoknak: x64, 


DEP (AMD xD, Intel nX) és virtualizációtá- 
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mogatás (Intel VI, AMD.V). Ilyen, valljuk 
be, még az otthoni gépünk is lehet, csak le- 
gyen belőle legalább kettő. Szükségünk van 
továbbá a jól megszokott különálló DC és 
ISCSI target szerepkörű gépünkre (2. kép). 
Itt természetesen a Fibre Channel is meg- 
él, sőt, teljesítmény szempontjából melegen 
ajánlott. 

A telepítés részleteivel nem untatnám a 
kedves olvasót, hiszen aki látott már clus- 
tert, gépiesen kattintgatva telepíti a leendő 
node-okat , egyformára", lépteti tartományba 
és konfigurálja a hálózatot. Egyszer csak min- 
den együtt van ahhoz, hogy nekilássunk a 
Host Cluster építésének. Hogyan? 

Nagy vonalakban valahogy így: 

1. Telepítsük fel a HyperV szerepkört 
mindkét gépre. Ez gond nélkül megtörténik, 
még akkor is, ha a hardverünk által támoga- 
tott (naná, mi választottuk ezt a gépet!) VT 
paraméter a BIOS-ban ki van kapcsolva. Ez 
sok gépen alapértelmezés! A HypervV ezt te- 
lepítéskor nem vizsgálja, csak az első virtuális 
masina indításakor. Akkor aztán elég egy- 
értelmű hibaüzenetet kaphatunk, miszerint 
nem lesz itt semmiféle virtualizáció, ugyan- 
is a hypervisor nem töltődött be. Jó tanács: 
kapcsoljuk be jó előre a VILt! 

2. A Hyperv telepítése a Virtuális Switch- 
ek konfigurálásával folytatódik. Még egy jó 
tanács: tehetünk bármit a virtuális hálózat 
tal, de azt a bármit teljesen egyformán te- 
gyük mindkét node-on! Egy karakternyi el- 
gépelés az egyik virtual switch nevében már 
elég ahhoz, hogy jóval később a 3. képen lát 
ható üzenetet kapjuk. 

3. Haladjunk tovább! Konfigurálta közben 
valaki az iSCSI targetet? Legyen (Puorum és 
néhány adatdiszk, a méretezéskor figyeljünk 


oda, hogy Windows Server 2008-at telepí- 
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3. kép. Mi is van most a hálózattal? 


tünk majd a virtualizációba, és az így létrejö- 
vő vhd állomány legalább 6 gigabájt! 

Az ISCSI initiator - szerencsére - alapér- 
telmezés szerint ott van a node-okon, akti- 


váljuk és csatlakozzunk a targethez. Járjunk 
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E CÍMLAPON 






el pont úgy, ahogy a Windows Serverek ko- 
rábbi verzióival tennénk, azaz cluster-szerviz 
nélkül ne lássák a node-ok egyszerre a formá- 
zott logikai egységeket a target mögött! Ugye, 
azért mindkét noderól látjuk a diszkeket? 

4. Jöhet a Failover Clustering telepíté- 
se mindkét node-on. Ez egy Feature check 


boxának bebillentése, egyszerűen elvégezhe- 


fürtözni, lehet bármelyik node-nak önálló, 
Sajat vittualizaciós Teladatas Válasszuk azt 
amelyik a közös diszkre lett telepítve. Ennek 
feltétele, hogy a guest legyen kikapcsolva. 
Sikerült? Kész vagyunk, ha... 

8. ...ha sikerül a virtuális gép mozgatása 
a node-ok között a cluster konzolból. (Na, 
itt kaphatjuk a fent jelzett virtuális network 


switch port problémájával kap- 
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csolatos üzenetet, ha valamit el- 





z Action Yew Help 
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rontottunk.) 








2. Fallover Cluster Management 
d új testcluster.hypervtest. local 
d E Services and Apolicatons 
j 
ma (3 Nodes 
(Cá Storage t 
ma E Networks Status: Online 
A Cluster Events Alerts: none; 
Preferred Owners: none; 


Current Owner: nodezs 


Virtual Machine Service 


— Virtual Machine aaa 


Disk Drives 





E Cs Cluster Disk 4 





Virtual Machine HAVM1 Recent Ciuster Events- 


-. o Summary of Virtual Machine HAVM1 





(2) Online 
I Virtual Machine Config... (e) Online 


(£) Online 


Ezzel megcsináltuk a host 
eclustert Windows Server 2008- 
ban HyperV-vel. Igen, de nem 
ez az igazi újdonság, ilyet némi 
fúrás-faragás-hegesztés árán a 
Microsoft Virtual Server 2005 
R2-vel is előállíthattunk, főleg 
ha a szabadon letölthető , havm. 
vbs" scriptet is bevetettük. A 
hagy. öröm inkább az, hogy 








4. kép. Magasan rendelkezésre álló VM 


tő, utána következhet a környezet ellenőrzé- 
sének procedúrája (Validate), ez kicsit idő- 
igényes, de így legalább meggyőződhetünk a 
tesztkörnyezet alkalmasságáról. 

5. A következő lépésben szülessen meg a 
cluster! (Nem ez a cikk hivatott pontosan 
leírni a lépéseket, de annyit meg kell jegyez- 
nem, hogy a folyamat roppant egyszerű, a 
varázsló teszi a dolgát.) Gyors ellenőrzés: há- 
lózatok OK, diszkek online állapotban, egy 
tesztcélú applikációs csoportban mozgatha- 
tók a node-ok között. 

6. Térjünk vissza az egyik node-on a Hyper 
V Managerbe (jellemzően azon a node-on, 
amelyik a megosztott diszkeket tulajdonol 
ja), és készítsük el a virtuális gépünket. Itt a 
konfigurációs állomány és a virtuális diszk 
helyére figyeljünk: mindkettőnek a kiszemelt 
megosztott diszken kell lennie. Ha megvan, 
telepítsünk bele egy Windows Server 2008- 
at, és készüljünk fel a fináléra. Már csak egy 
lépés, és készen vagyunk! 

7. A virtuális gép beillesztése a Clusterbe 
egyszerűbb, mint gondolnánk. Induljunk a 
Configure a Sevice or Application varázs- 
lóval a Failover Cluster Management kon- 
zolon. Mit szeretnénk clusterbe szervez- 
ni! Választható a Virtual Machine, mint 
resource-típus! Akkor azt. Jó, de melyiket? 


Nem muszáj az összes virtuális gépünket 
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ilyesmivel itt nem kell bíbelőd- 
ni, az operációs rendszer és a 
virtualizáció igen szép integrá- 
cióról tesz (már most) tanúbizonyságot, pedig 
hol van még az RTM, különösen a HyperV 
végleges változata. 

És még valaminek örülhetünk, ami szin- 
tén nem egy utólag beillesztett scriptnek kö- 


szönhető: ez pedig a Ouick Migration. 


Ovick Migration — az állapot 
megőrzése 

Gondoljunk csak bele, hibatűrő rendszerünk 
van - viszont jön egy tervezett, de elkerülhe- 
tetlenül sürgős beavatkozás, ami miatt csü- 
törtök délben a cluster egyik nodeját le kell 
állítani. Mi legyen? Ha átmozgatjuk a virtuá- 
lis gépünket a másik node-ra, akkor számol 
nunk kell annak leállásával, azaz a benne 
futó szolgáltatás és az operációs rendszer is 
jó időre kivonja magát a forgalomból. Ez még 
fájóbb akkor, ha épp olyan folyamat zajlik a 
virtuális gépen, amit megszakítani sehogy 
sem szerencsés, hiszen olyan régen küzd a 
feladattal, és most elölről kell kezdenie sze- 
génynek... 

Jó hír: nem kell! Nem kell leállítani, leg- 
alább is a szó megszokott , shut down" értel 
mében semmiképp. Iud Hyper-V állapotot 
menteni, mielőtt kiiktatnánk a guestet a for- 
galomból? Persze hogy tud, hiszen ez alapve- 
tő tulajdonsága még a Virtual PC-nek is. 

Ezt a Faiover Cluster is tudja a Hyperv- 








ről, az 5. képen látható a bizonyíték. Érdekes 
képernyővel szembesülünk a mozgatáskor! 
Mindez tényleg azt jelenti, hogy a moz- 
gatást megelőzi az állapot mentése a közös 
diszkre, ahonnan a másik node - az új tu- 
lajdonos - a mentett állapotot olvassa fel. 
Hogy mennyi időt vesz igénybe? Ez legin- 
kább a diszkkel való kommunikáció sebes- 
ségétől függ, de a mi tesztkörnyezetünkben 
átlagosan az állapotmentés 17, a mozgatás a 
függőségi viszonyoknak megfelelő leállítással 
és a másik node-on való újraindítással 5, az 
állapot visszaállítása (tehát a guest hadrend- 
be állítása) 15 másodpercig tartott. Az any- 
nyi, mint 37 másodperc! Iudunk ennyi idő 
alatt egy szabályos leállítást és újraindulást 
produkálni? Úgy gondolom, nem. A Ouick 


Migration funkció rászolgál a nevére. 


Ovick Migration vagy Live 
Migration? 

Még egy gondolat, ami szorosan illeszkedik 
ehhez a témához: a virtualizáció és a fürtszol 


gáltatás kapcsolatára jellemző, hogy együtt 


milyen leállásokat képesek tolerálni, és per- 





Virtual Machine Service 


Zz Virtual Machine aza ae Offline Pending (Saving VM, 917. completed) 
HT Virtual Machine Config... (4) Online 








5. kép. Az állapot mentése. . . 





Virtual Machine Service 


Iz Virtual Machine azza pe Online Pending (Restoring VM, 567. completed) 
3 Virtual Machine Config... (£) Online 








6. kép. . . .és visszaállítása a másik node-on 


sze az is, hogy hogyan. A leállások, amelyek- 
nek tanúi és sok esetben szenvedő alanyai 
vagyunk, jellemzően kétfélék: tervezettek és 
meglepetésszerűek. 

Előbbire jó előre felkészülünk, és csak 
akkor nyomjuk meg az átterhelést elindító 
, nagy piros gombot", amikor komoly esély 
van arra, hogy a rendszerünkbe szervezett 
szolgáltatások igen rövid időn belül - és főleg 
adatvesztés nélkül - ismét teszik a dolgukat. 
Igen rövid idő? Mennyi is az pontosan? Ha 
az előzőekben tárgyalt Ouick Migration mű- 
ködését megértettük, akkor belátható, hogy 
ez bizony nagymértékben függ a környezet 
változóitól. 


Ami annyit jelent, hogy bár mozgatáskor 
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a virtuális gépünk egy kis ideig nem érhető 
el, de amikor új erőre kap, akkor ott folytat 
ja, ahol abbahagyta. Nem lehetne megúszni 
köztes idő nélkül? Dehogynem, az eszme 
megvan, úgy hívják, hogy Live Migration, 
vagy más néven Hot Migration. Kicsit utá- 
na olvasgatva a témának, könnyen rálelhe- 
tünk azokra a virtualizációs témájú blogokra, 
amelyek szerint nemcsak az eszme van meg, 
hanem az ígéret is: benne lesz a Windows 
Server 2008-ban - egy későbbi kiadásban. Itt 
a mozgatás, azaz a host tervezett leállásából 
adódóan a guest egy másik nodera való át 
terhelése közben a kapcsolat a szolgáltatással 
kliensoldalról nézve nem vagy csak nagyon 
rövid időre (kevesebb mint egy másodpercre) 
szakad meg. A megoldást türelmesen és kí 
váncsian várjuk! 

Végül gondoljunk bele, mi történik tervez- 
hetetlen, meglepetésszerű leálláskor! Jóllehet 
clusterbe szerveztük a virtuális gépet, és bár 
a cluster teszi a dolgát, az könnyen belátható, 
hogy ebben az esetben nem számolhatunk a 
mentett állapottal és annak helyreállításával. 
Virtuális gépünk újraindul, és hála a fájl 


rendszernek, illetve az alkalmazás esetleges 


recovery mechanizmusainak, majdnem ott 
folytathatja, ahol abbahagyta. Jó esetben. 
Reméljük a legjobbakat. És ha nem? Erre bi 
zony készüljünk csak fel, hiszen nincs olyan 
rendszer, ahol a mentés vagy egy jól átgon- 
dolt stratégia vész esetére teljesen felesleges 
lenne! Ha nem készültünk fel, még mindig 
ott a lehetőség egy jó kis bitvadászatra. Vagy 


marad a varázslat. 


Végítélet 

A virtualizáció jelentősége és jövője megkér- 
dőjelezhetetlennek látszik, főleg ha a magas 
rendelkezésre állással is párosul. Az üzemel 
tetők többsége értékeli a kisebb-nagyobb fel 
adatokkal ellátott, különböző gyártmányú, 
korú és kapacitású szervereinek konszolidá- 
ciós lehetőségét kevesebb fizikai hardver fölé, 
főleg akkor, ha az így konszolidált szerverek 
eszközkezelőkből fakadó hardverfüggősége 
innentől megszűnik. Melyik rendszergazda 
vagy fejlesztő ne használna olyan tesztrend- 
szert, amelyik bármikor, pillanatok alatt elő- 
állítható, és ráadásul pont ugyanolyan, mint 
a végleges? Végül essen szó a nagy adatköz- 


pontok fizikai gépeinek dinamikus terhelhe- 
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tőségéről is, guick vagy live migrációval mára 
Tmár ez Sem VÍZIÓ. 

Ami pedig tény: Láthatunk egy RCI1 ál 
lapotban lévő operációs rendszert egy olyan 
- sok szempontból megújult - Cluster szol 
gáltatással, amit nem ez a cikk hivatott fel 
tárni, erről ugyanebben a számban is olvas- 
hatunk részletesen. Kipróbálhatunk egy bé- 
tastátuszban lévő virtualizációs megoldást, a 
Hyper-V-t, aminek a belvilágáról szintén nem 
ebből az írásból kell tájékozódni, de mikro- 
kerneles Iype l-es virtualizációról van szó, 
és ez bizony teljesítményben és megbízható- 
ságban sokat ígér! (A HyperV-rre a teszt so- 
rán talán egyetlen komoly panaszom lehet: 
sikerült létrehozni egy virtuális gépet, amit 
később sehogy sem sikerült letörölni a kon- 
zolból. Ennél nagyobb baj bétaszoftverrel ne 
legyen.) Integráltuk a Clustert és a Hyper-V-t, 
építettünk több fajta guest clustert, és köny- 
nyűszerrel összejött a host cluster Windows 
Server 2008 x64 full install környezetben. 
Csináljuk végig legközelebb ugyanezt Server 
Coreral is! 

Székács András 
(andras(Dedupro.hu), MCT, MCSE, MCTS, Számalk 
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A központosított adattárolók (storage-ok) világa sokunk számára 


tűnik titokzatosnak, bonyolultnak és nehezen megközelíthetőnek. 


Ez a titokzatosság azonban remélhetőleg jelentősen csökken majd, 


ahogy gyakoribbá válnak az adattároló megoldások 


a kis- és középvállalati körben is. 


és az adattárolók összekapcsolását egyszerűsítik le, és teszik elérhetővé ezek használatát a 


F bben az írásban azokat az eszközöket mutatom be, amelyek a Windows Server kiszolgálók 
különleges ismeretekkel nem rendelkező rendszergazdák számára is. 


Storage-egyszeregy 

Első lépésként mindenképpen érdemes egy kis elméleti áttekintéssel és fogalommagyarázattal 
kezdeni az ismerkedést az adattárolókkal. Annál inkább szükségesnek tűnik ez, mert annyi- 
ra különleges területről van szó, hogy a legtöbb témához kapcsolódó kifejezésnek nincs széles 
körben elfogadott magyar szaknyelvi megfelelője sem. Már az adattároló kifejezés használata is 
kompromisszum eredménye - pontosabb kifejezés hiányában használom a Data Storage ma- 
gyar megfelelőjeként. 

Adattárolóinkat többféle szempont szerint csoportosíthatjuk, az egyik legkézenfekvőbb 
mindjárt az, hogy milyen módon csatlakoznak kiszolgálóinkhoz. A leggyakrabban használt 
csoport minden bizonnyal a közvetlenül csatlakoztatott adattároló (Direct Attached Storage 
- DAS), hiszen ez jelen van csaknem minden kiszolgálóban és asztali gépben is. Ebbe a cso- 
portba tartoznak az ATA, SATA és SCSI csatolófelületű belső és külső diszkek. A technoló- 
giai megoldás vitathatatlan előnye, hogy az adattároló eszközöket nagy sebességgel érjük el, az 
átviteli sebesség másodpercenként 80-100 megabájttól akár 640 megabájtig is terjedhet. Ez a 
sebesség viszont egyedül annak a gépnek áll rendelkezésére, amelyikhez az eszközöket csatla- 
koztattuk. Kivételnek csak a kétportos külső SCSLadattárolók számítanak, amelyeket gyakran 
használnak egyszerűbb fürtök (2-nodes failover cluster) adattárolójaként. Ha további gépek 
számára szeretnénk elérhetővé tenni a DAS-eszközök tárolókapacitását, akkor azt csak hálóza- 
ton, az operációs rendszer nyújtotta protokollon keresztül tehetjük meg, számottevően kisebb 
sebességgel. 

Az adattárolók következő csoportja a hálózati adattároló (Network Attached Storage 
- NAS). Ezek - beágyazott operációs rendszerüknek köszönhetően - önálló egységként jelen- 
nek meg a hálózaton, és valamely népszerű hálózati protokollon (általában CIFS vagy NFS) 
keresztül érhetők el a felhasználók számára. A komolyabb eszközök már hibatűrő diszkrend- 
szert tartalmaznak, de sebességük lényegesen elmarad a DAS-eszközökétől, hiszen osztozni 


kell más felhasználókkal a hálózati sávszélességen, és az alkalmazott protokoll is lassító tényező 


Ki 


- erről kicsit később még lesz szó. Határozott 
előnyük viszont a NAS-eszközöknek, hogy a 
tárolókapacitás független az egyes számítógé- 
pektől, és akár egy másik telephelyen is ren- 
delkezésre állhat - az egyetlen követelmény a 
TCP/IP-kapcsolat és a megfelelő protokollok 
átengedése a tűzfalakon. 

A legkülönlegesebb (és egyben legköltsé- 
gesebb) adattárolási megoldás az adattárolási 
hálózatok (Storage Area Network - SAN) al 
kalmazása. Ebben az esetben ugyanis nem 
az az elsődleges cél, hogy a végfelhasználók 
számára közvetlenül biztosítsunk nagy táro- 
lási kapacitást, hanem hogy a kiszolgálóink 
érjenek el nagy tárolási kapacitásokat, nagy 
sebességgel és szükség esetén megosztott mó- 
don. Az így létrejött tárhelyet persze ki is 
ajánlhatjuk a felhasználók számára egy fájl 
kiszolgáló esetén, de az esetek többségében 
inkább kiszolgálóoldali alkalmazásoknak ad- 
juk at peldáuldádatbázisok tárolásátas vagy 
fürtözött rendszerek közös tárhelyeként. A 
leggyakrabban használt technológiai megol 
dás a SAN-eszközök esetén az optikai hálóza- 
tok és a gyors SCSLdiszkrendszerek együttes 
alkalmazása. Az optikai hálózat akár másod- 
percenkénti 10 gigabit átviteli sebességet is 
képes nyújtani több száz méteres (súlyosabb 
pénztárca esetén akár 100 kilométeres) távol 


ságra is. A leggyakrabban alkalmazott FCP 


Microsoft TechNet 





KE CÍMLAPON 






(Fibre Channel Protocol) protokoll pedig 
a jól ismert SCSI protokoll egy változata, 
amely blokkszintű, nagy sebességű elérést 
biztosít a diszkekhez (a leggyakoribb 2 vagy 4 
gigabites hálózatok esetén ez 250, illetve 500 
megabit névleges átvitelt jelent). 

Az optikai hálózatra épülő adattárolási 
rendszerek egyik legnagyobb hátránya a ma- 
gas kiépítési költség. Ennek ellensúlyozására 
fejlesztették ki és szabadalmaztatták 2003- 
ban az IiSCSI protokollt, amelynek alapel 
ve rendkívül egyszerű. Az SCSI-parancsokat 
és az adatokat, amelyeket a diszkrendszer- 
nek akarunk küldeni, csomagoljuk TCP/IP- 
csomagokba, és küldjük át a hagyományos 
Ethernet hálózaton! Így - némi teljesítmény- 
áldozat aran — mectakarítható a drága opt 
kai hálózat kiépítése, az adattárolási hálóza- 
tot a meglévő (lehetőleg) gigabites hálózatun- 
kon létre tudjuk hozni. TIermészetesen ezt a 
hálózatot gondosan el kell különíteni a fel 
használói hálózattól (például VLAN-techno- 
lógiával), és biztosítani kell az adatok bizton- 
ságát is, ezért építettek be az iSCSI protokoll 
ba IPSectámogatást. Ráadásul visszakapjuk 
a NAS-eszközöknél látott rugalmasságot is 
- az ISCSI protokoll használatával akár telep- 
helyeket, országhatárokat átívelő adattárolási 
hálózatokat hozhatunk létre, csupán TCP/ 
IP-kapcsolatra és megfelelő tűzfalszabályokra 
van szükség. 

Az iSCSLtechnológia alkalmazása elérhe- 
tővé teheti a SAN-technológiát olyan válla- 
latok számára is, amelyeknek a hagyományos 
SAN kiépítése túl magas költségekkel járt 
volna. Egyes piaci elemzések szerint az iISCSL 
technológia alkalmazására 2007-ben már 1 
milliárd dollárt költöttek az amerikai vállala- 
tok, az iSCSI alapú SAN-kapcsolatok száma 
pedig elérte a 6,5 milliót. 

Összefoglalásként helyezzük el a különbö- 
ző adattárolási megoldások protokolljait az 
OSI-ISO modellben! Az egyes protokollok 
elhelyezkedését vizsgálva jól látható, hogy az 
adatátvitel hatékonysága annál jobb, minél 
alacsonyabb szinten valósul meg, hiszen az al 
sóbb régiókban az adatok átvitele blokkszin- 
ten valósul meg, szemben a NAS-eszközök- 
kel, ahol az adatátvitel fájlszintű, rárakódik a 
magasabb szintekre, és onnan visszaalakítás- 
többlet a számításigénye. Az is igaz viszont, 
hogy a megvalósítás költségeivel éppen fordí- 
tott a helyzet: minél magasabb szintű proto- 


kollt használunk, annál olcsóbb a megvalósí- 
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tás, főként mert az alkalmazott technológia 
szélesebb körben elterjedt. 

Mivel az iSCSI viszonylag új és remélhe- 
tőleg itthon is széles körben megjelenő tech- 


nológia, ismerkedjünk meg vele kicsit köze- 


lebbről. 


Mit tud az ISCSI? 


Definíciószerűen fogalmazva az iSCSI olyan 
protokoll, ami lehetővé teszi a kliensrendsze- 
rek számára (ezeket hívja az angol szaknyelv 
initiatormak) " hogy mormálörebUP-hálózas 
ton keresztül SCSLparancsblokkokat küld- 
jenek SCSLadattároló eszközöknek (ezek a 
targetek). Mindeközben a kliensek a diszk- 
eszközöket úgy látják, mintha helyileg (te- 
hát DAS-ként) csatolt diszkekről lenne szó. 
Szemben a hasonló szolgáltatást nyújtó opti- 
kai SAN-rendszerekkel, az iSCSI nem igényel 
különleges kábelezést, és a hagyományos há- 
lózati infrastruktúrát használva nagy távolsá- 
gokra is továbbítható. 

Az ISCSI elméletileg bármilyen SCSI-kom- 
munikációt lehetővé tesz a megfelelő szoftve- 
res vagy hardveres átalakítók közbeiktatásá- 
val, a gyakorlatban azonban a két legelter- 
jedtebb alkalmazási területe az adattárolási 
rendszerek konszolidálása (szétszórt adatok 
központosított tárolása) és e rendszerek ka- 
tasztrófatűrővé tétele az adattárolási rendsze- 
rek tükrözésével a telephelyek között. 

Az iSCSIkliensek elsődleges feladata, hogy 
az SCSLparancsokat IP-ccssomagokba helyez- 
zék, és ebben a formában továbbítsák az adat 
tároló kiszolgáló felé. Alapvetően két meg- 
valósítási formája létezik: szoftveres és hard- 
veres. A szoftveres változat tulajdonképpen 


egy kernelszintű eszközvezérlő, ami a hálózati 
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kártyával és az operációs rendszer hálóza- 
ti komponenseivel együttműködve dolgozik. 
Jelentős előnye, hogy szinte minden modern 
operációs rendszerben használható: vagy ele- 
ve beépített komponens - mint a Windows 
Vista és a Windows Server 2008 esetében 
-, vagy utólag telepíthető csomag, mint a 
Windows XP és Windows Server 2003 és a 
szabad forráskódú rendszerek esetében. 

A hardveres változat egy PCLcsatolófelü- 
letű hibrid Ethernet-iSCSI host bus adapter 
(HBA) kártya, ahol az isCSLkapcsolat felépí- 
tése és a kapcsolódó számítások nagy részé- 
nek elvégzése a hardver és az azt üzemeltető 
célszoftver (firmware) feladata. Nyilvánvaló, 
hogy a hardveres megoldás lényeges jobb tel 
jesítményre képes, mert tehermentesíti az 
operációs rendszert az iSCSIrműveletek szá- 
mításai alól. Ráadásul egy kiegészítő ROM 
közbeiktatásával lehetővé teszi az operációs 
rendszer SAN-ól történő indítását is, így egy 
ISCSLkliens akár helyi diszkek nélkül is üze- 
meltethető. 

Az ISCSI adattárolók (targetek) nagyvál- 
lalati környezetben általában célhardverek: 
kifejezetten iSCSI felületű adattárolók vagy 
hagyományos SAN-eszközök, és eléjük te- 
lepített ISCSI felületű optikai átalakítók 
kombinációja. Az egyszerűbb és így kevésbé 
költséges megvalósításokban ez gyakran egy 
hagyományos kiszolgáló, isCSLtudással fel 
ruházva, mint például a Windows Storage 
SENMEGZOÜ BE 

A klasszikus SCSIhoz 
isCSLadattárolók diszkjeit is azonosító szá- 
mokkal látjuk el, ezek a LUN-ok (logical unit 
number). Míg azonban az SCSLnél ez egy- 


hasonlóan az 


egy fizikai diszk azonosítója, addie az 15CSI 


8 Tipikus protokollok Azottáralási 
száma — neve megoldás 
7 Application SIP, DNS, FTP, HTTP, NFS, NTP, SMTP, SNMP, Telnet, X.400, X.500, CIFS  NAS 
6 Presentation .  TDI, ASCII, EBCDIC, MIDI, MPEG, MIME, SSL 
8] Session Named Pipes, NetBIOS, NWLink, X.225, iSCSI ISCSI, SAN (FC) 
4 Transport TCP, UDP, IPSec, PPTP, L2TP, SPX SAN (FC) 
3 Network IP, ARP, ICMP, DHCP, RIP, OSPF, IGMP, X.25 (PLP), IPX SAN (FC) 
bon Zion MEYAGYZUC NTI MAN arg 
] Physical RS-232, TI, ET, TOBASE-T, T0OBASE-TX, DSL, 802.11a/b/g/n PHY SAN (FC) 
1. táblázat. A különböző adattárolókon használatos protokollok helye az 0S5I-modellben 
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esetén logikai egységet jelöl, ami feltehetően 
egy hibatűrő diszkrendszer egy szelete, ezt 
felajánljuk a kliensek számára. Bizonyos imp- 
lementációkban az így megjelenített diszk 
egy virtuális diszk, ami az adattárolón fájl 
ként látható, a kliens felé pedig teljes értékű 
diszkként. A Windows Storage Server 2003 
például kompatibilitási okokból és az árnyék- 
másolatok egyszerű támogatása érdekében 
a Microsoft szabványos VHD formátumát 
hasznalja 

A kliensek és az adattárolók összekapcso- 
lását címzéssel kell biztosítanunk. Három 
címzési forma szabványos, a leggyakrabban 
az ION-t (ISCSI Cualified Name) használják: 
ez nem igényli az eszköz regisztrációját. A 
cím egy dátumot (év-hónap) és egy fordí- 
tott doménnevet, valamint az eszköz azono- 
sítóját tartalmazza például ilyen formában: 
ign.2001-04.com.acme:storage.tape.sys1.xyz. 
A használt rendszertől függően az ICON-t ma- 
gunk is generáltathatjuk, vagy a doménnevet 
és az egyedi azonosítót helyettesíthetjük az 
adattároló IP-címével. A másik két címzé- 
si forma regisztrációt igényel, mindkettőt az 
IEEE szervezet bocsátja ki. Az EUI (Extended 
Unigue lIdentifier) címzés 64 bites (például 
eui.02004567A425678D), az NAA (Network 
Address Authority) 64 vagy 128 bites (példá- 
ul naa.02004567A425678D). Az utóbbi cím- 
zési forma teljesen kompatibilis az optikai 
adattárolókon használatos címzési formák: 
kal, és mindkettő teljesen egyedi azonosító. 
Ezek a címek az optikai rendszerekben hasz- 
nált WWN (World Wide Name) azonosítók 
megfelelői az iSCSLra értelmezve. 

A kapcsolat felépítéséhez általában négy 
adatot kell használnunk: az adattároló kiszol- 
gáló nevét vagy IP-címét, a használandó por- 
tot (az alapértelmezett a 3260-as TCP-port), 
az eszköz címét valamilyen szabványos formá- 
ban és opcionálisan az azonosításhoz szüksé- 
ges jelszót (CHAP secret). 

Ezzel máris elérkeztünk a biztonság kér- 
déséhez, és itt érdemes alaposabban elidőz- 
nünk, hiszen a SAN-hálózatok - és így egy 
iSCSLra épülő SAN is - a legértékesebb ada- 
tainkat hordozhatják. Korántsem mindegy 
tehát, mennyire tudjuk biztonságban tartani 
ezeket az adatokat. Az első és legfontosabb: 
mivel az ISCSLkapcsolatok a hagyományos 
Ethernet hálózatot használják, és TCP/IP 
csomagokból épülnek fel, a mi feladatunk, 


hogy ezt a forgalmat a lehető legjobban el 
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Operációs rendszer . Bevezetésideje Verzió Elérhető funkciók 
15/05 2006. 10. 15/05 VSR4MO Target, Multipath 

AIX 2002. 10. AIX 5.2 Initiator 

Windows 2003. 06. 2000, XP Pro, 2003, Vista, 2008 Initiator, Target, Multipath 
NetWare 2003. 08. NetWare 5.I, 6.5, 8. 0ES Initiator, Target 

HP-UX ZO08 0 HP Ti vI, HP Ti v2 Initiator 

Solaris 2005. 02. Solaris 10 Initiator, Target, Multipath 
Linux 2005. 06. 70902 Initiator, Target, ISER 
NetBSD 2006. 02. 4.0, 5.0 nitiator (5.0), Target (4.0) 


2. táblázat. Az iSCSI támogatása az egyes operációs rendszerekben 


különítsük a felhasználói hálózattól, és kü- 
lönösképpen, hogy megakadályozzuk ennek 
a hálózatnak mindenfajta kommunikációját 
az internet felé (hacsak nem kifejezetten egy 
ilyen szolgáltatáshoz szeretnénk kapcsolód- 
ni). A legjobb és leghatékonyabb a teljes fizi- 
kai elkülönítés (külön kábelezés és switch-ek 
használata), de az esetek többségében egy 
pontosan meghatározott VLAN és gondosan 
beállított tűzfalszabályok is elérik a kívánt 
eredményt. Ezzel az elkülönítéssel az auten- 
tikációra egyelőre kizárólagosan használható 
CHAP (Challenge Handshake Protocol) köz- 
ismert sebezhetőségét is számottevően csök- 
kenthetjük. Nagyobb rendszerek esetén sze- 
rencsés, ha az azonosításba egy RADIUS ki 
szolgálót is bevonunk, ezzel csökkenthetjük 
az egyedi adminisztratív hibák lehetőségét. 

Fontos (tudnunk "azt is, hogy az 15C5SL, 
több más SAN-protokollhoz hasonlóan, nem 
tartalmaz semmiféle beépített titkosítást, így 
aki hozzáférhet az iSCSI-hálózat forgalmá- 
hoz, az képes megszerezni vagy akár módosí- 
tani is az ott áramló adatokat. Ezt a veszélyt 
IPSec alkalmazásával háríthatjuk el, bár ezt 
viszonylag ritkán alkalmazzák, főleg a több- 
letszámításigény és a konfigurálás bonyolult 
sága miatt. 

Az egyes ISCSLfunkciók operációsrendszer- 


támogatását a fenti táblázat mutatja be. 


Építsünk saját storage-et! 

Az elméleti áttekintés után nézzük az iSCSI 
rendszer egy lehetséges gyakorlati alkalma- 
zását! A következőkben szeretném megmu- 
tatni, mennyire egyszerű a kapcsolódás az 
adattárolóhoz, és a szolgáltatás felhasználá- 
sával milyen egyszerűen építhetünk például 


magas rendelkezésre állású rendszereket. A 


példában használt eszközök közül a Storage 
Manager for SANs már a Windows Server 
2003 R2-es változatában is telepíthető össze- 
tevő (a Storage Explorerrel együtt), míg az 
ISCSI Initiator a Windows Vista és a Win- 
dows Server 2008 beépített komponense, kü- 
lön telepítést sem igényel. (Korábbi Windows- 
verziókhoz az iSCSI Initiator ingyenes letöltés 
formájában elérhető a Microsoft oldalán.) 

A cél egy Windows 2008-tartomány fel 
építése, amiben a DHCP és fájl szolgálta- 
tást fürtözött Windows Server 2008-kiszol 
gálók nyújtják. A tartományvezérlő érdekes- 
ségképpen legyen egy Server Core-változat 
a Windows Server 2008-ból, az adattároló 
pedig az egyszerűség kedvéért egy Windows 
Storage Server 2003 R2. Lássunk hozzá! 

Az első lépés természetesen a tartomány 
felépítése és a kiszolgálók telepítése, illet 
ve beléptetésük a tartományba. Mikor ezek- 
kel a lépésekkel megvagyunk, akkor fogha- 
tunk neki az adattároló konfigurálásának. 
Virtuális környezetről lévén szó, elegendő 
lett volna néhány virtuális diszk fájlt létre- 
hozni és a Storage Server alá csatolni. Most 
az érdekesség kedvéért egy külső Firewire 
diszket is csatlakoztattam a géphez, hogy ki- 
próbálhassam, hogyan kezeli a HyperV a fizi- 
kai diszkeket. (Fizikai diszket csak úgy csatla- 
koztathatunk virtuális géphez, ha az a gazda- 
rendszer számára offline státuszban van.) A 
Storage Server telepítése nem bonyolultabb, 
mint egy átlagos kiszolgálóé, csak az R2-kom- 
ponensek telepítése után kell még néhány 
percet várnunk, amíg a megfelelő kiegészítő 
szolgáltatások települnek egy script segítségé- 
vel. Persze, aki ilyen rendszert szeretne hasz- 
nálni, az sosem fog találkozni ezzel a lépéssel, 


mert a Storage Server 2003 csak hardverrel 
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Healthy (System) 29.99GB 25.12GB 8394 No 095 





ls. Dynamic NTFS Resynching :(...  97.66GB 97.57GB 9996 0 Yes 5096 
Es... ! Simple Dynamic NTFS Healthy 12.SOGB 12.44GB 9994 No 09 
SS... Striped Dynamic NTFS Healthy 33.67 GB 33.6OGB 99946 0 No 09 
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ú Management í 
m-a Services and Applications 290isk 0 8 
Basic (C:) 
29.99 GB ő29cemrs 
Online Healthy (System) 
GYVISk 1 
Dynamic Mirror Set (F-) "Stripe Set (D) 
114.49 GB 97.66 GB NTFS 16.83 GB NTFS 
Online IResynching : (396. Healthy 
GDISsk 2 
Dynamic Mirror Set (F:) Stripe Set (D:) Simple volume (E:) 
126.99 GB 97.66 GB NTFS 16.83 GB NTFS 12.50 GB NIFS 
Online [Resyndhiny : (390) Healthy Healthy 
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CD-ROM (Z:) 
No Media 
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File 
You can create a virtual disk using a new file. 








dr I5CSI virtual disk is created as a virtual disk (.vhg] file. To specify a file to be used asz 
an ISCSI virtual disk, tupe the full path (for example, CS amplevvirtual Disk, 1.vhd]. 





Browse... 
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Access 
Specify the I5CSI targets that vou want to be able to access the virtual disk. lÉ you 
want to provide access to a cluster environment or a SAN file system, specify each 


I5 CSI target name. 








15CSI targets that can access this virtual disk: 


Target Name mee DESOTDtTON ener] 


Demo for TechNet : 
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sÍ? Microsoft ISCSI Soflware Target 
5-8 iscsI Targets 














ay sor. jomo esdipt Access b) 
ea Devices Virtual Disk for DHCP elustering  100.00MB Ide — storago-domo 
s €) Snopshots 87.89GB — Ide storage-demo 
(d) active snapshots 32.23GB Ide — sturage-demo 
ő Schedulcs 


Mirror Set (F:) 
97.66 GB NTFS 
Free space: 9.60 GB 


Stripe Set (D:) 
16.09 GB NTFS 
Free space 1.37 GD 


Mirror Set (F-) 
37.66 GB NTFS 
Free space: 3.68 GB 














2. ábra. A virtuális diszkek létrehozásának folyamata 


kedik el (stripe set) és 
egy 12 gigabájtos egysze- 
rű kötetet. 

A következő lépés a 
diszkek létre- 
hozása és engedélyezé- 
se az ISCSI Software 
Target MMC-ben. A mű- 


velet egyszerű, a szoká- 


virtuális 


sos módon varázsló ve- 
zet bennünket végig a 
folyamaton. Először meg 
kell adnunk a virtuális 
diszk elérési útját és ne- 
vét. Ebből kivételesen az 
elérési út a fontosabb, 
mert ez dönti el, hogy 
milyen hibatűrésű fizi- 
kai diszkre kerül a vir 
diszkfájl, tehát 
mennyire lesz védve az 


esetleges diszkhibákról. 


tuális 


Hasonlóan fontos vé- 
giggondolnunk, hogy az 
adott fizikai diszken mi- 
lyen más virtuális disz- 
keket hoztunk/hozunk 
létre, hiszen ez döntően 
befolyásolhatja rendsze- 
rünk teljesítményét. A 
második lépésben meg- 
határozhatjuk a virtuális 
diszk méretét, a harma- 
dikban pedig hozzáféré- 
si jogot adhatunk a ki 
szolgálók számára. Mivel 
még nincsenek kapcso- 
lódó kiszolgálóink, egye- 
lőre adjunk jogot a helyi 
ISCSLkiszolgálónak! 

A következő  lé- 
pés a Windows Server 
2008-as kliensek csatla- 
koztatása, mert csak ez- 


után tudunk hozzáférést 


együtt vásárolható, és ott már elvégezte ezt a 
műveletet az OEM-gyártó. Az első valós lépés 
tehát, hogy csatlakozzunk a kiszolgálóhoz, 
és konfiguráljuk a rendelkezésre álló fizikai 
diszkeket. 

A rendelkezésre álló kapacitásból elég tar 
ka konfigurációt állítottam össze: egy 90 
gigabájt körüli RAlDLtömböt, egy 32 giga- 
bájtos kötetet, ami két fizikai diszken helyez- 


JANUÁR-FEBRUÁR 


biztosítani számukra a kiajánlott diszkek- 
hez. Fontos tudni, hogy az SCSIszabvány- 
nak megfelelően minden kliensgép csak a 
számára engedélyezett diszkekhez férhet hoz- 
zá, és az így adott jog kizárólagos, tehát amíg 
az adott gép használja a diszket, addig más 
eszköz nem. Ez nem áll ellentmondásban a 
fürtözött használattal, mert abban az eset 


ben majd a fürt virtuális nevéhez rendelünk 


TETT SO 7 
eg mene 
él ss 


hozzá diszkeket, és a fürt bármely tagja hozzá- 
férhet a diszkhez, de ebben az esetben is egy 
időben csak az egyikük! 

Lépjünk be tehát a Windows Server 2008- 
kiszolgálókra, telepítsük a Failover Cluster 
tulajdonságot (ha több hálózati csatolót hasz- 
nálunk, akkor a MultiPath [/O-t is!), és ál 
lítsuk be az ISCSÍ-kapcsolatokat! Az 15€CSI 
Initiator első indításakor figyelmeztetést ka- 
punk, hogy a szolgáltatás nem fut (érthető, 
hiszen a Windows Server 2008-ban alap- 
értelmezés szerint minden, ami nem feltét 
lenül szükséges, kikapcsolt állapotban van). 
Engedélyezzük a szolgáltatás elindítását, és 
jegyezzük meg, hogy ezzel egyúttal a megfele- 
lő tűzfalszabályok is bekapcsolódtak, tehát az 
ISCS-kliensünk már elméletben képes kom- 
munikálni az adattárolóval. 

Az elméletet váltsuk gyakorlatra a kliens 
beállításával. Az erre szolgáló ablakon csak 
hat fülecskét látunk, de a különböző gom- 
bok alatt azért számos állítási lehetőség rej- 
tőzik. Az alapbeállítások viszont egyszerűek: 
a Discovery fülön vegyük fel adattárolónkat 
a targetek listájára (használhatjuk a host ne- 
vét, a DNS nevét, vagy az IP-címét)! A Targets 
fülre átlépve a Refresh gomb hatására meg 
kell jelennie az adott hoston elérhető iSCSL 
targetek listájának (a mi esetünkben az ION 
neve jelenik meg). Az alapértelmezett állapot 
Disconnected, a Log on... gombra kattintva 
állíthatjuk be a kapcsolat paramétereit: az 
automatikus újracsatlakozást és a MultiPath 
engedélyezését, majd az Advanced gombra 
kattintva a CHAPjelszót és az IPSec tulaj- 
donságait. Itt dönthetünk arról is, hogy az 
egész autentikációt inkább egy RADIUS ki 
szolgálóra bízzuk, ebben az esetben fel kell 
vennünk gépeinket a RADIUS kiszolgálón 
is kliensként. Ha mindent jól csináltunk, 
akkor a Targets fülre visszatérve az adattá- 
rolónk már Connected állapotban lesz, ez 
pedig elegendő, hogy jogosultságot adjunk 
nekik az adattárolón. 

A Storage Serveeen nyissuk meg a Storage 
Manager for SANs MMC-t, és válasszuk 
a ENMamasc SEVEN CONMECHONS TODCIÓLE VA 
lasszuk a Manage Clusters gombot és adjuk 
meg a csatlakoztatandó fürt nevét (ezt már 
itt el kell döntenünk, és később majd ezzel a 
névvel kell létrehoznunk a tényleges fürtöt). 
A csatlakoztatott kiszolgálók listáján jelöl 
jük be azokat a kiszolgálókat, amelyek a fürt 
tagjaiként fognak működni, ezzel adhatunk 
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ESSENEK ad Té Failover Cluster Management 
Favorite Targets  ] — Volumes and ze ]  RADIUS j Favorite Targets —— ] — VolumesandDevices — ] — RADIUsS  ] File Action — View ! Help 
General Discovery Targets General l Discovery Targets b : 3 ma HF aa 
Target portals To access storage devices for a target, select the target and then click 


EZ Failover Cluster Management 


Log on. 
7 EZ Ws-CLU.wsdemo.local 
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To see information about sessions, connections, and devices for a target, - E Services and Applications 
sEksEe 3 KER ea FT ws-CLU-DHCP. 3 Online 
a Fan E. E I5-CLU-FS— ($)Online File Server WS-CLUT 
2 6 
Targets: éa szegi 
WwS-CLU1 
Add Portal... l Remove l Refresh l B Ws-aLu2 
ign. 1991-05. com. microsoft:storage-storage-d, .. . Connected fi 
TISNS servers (Ea Storage 




















4] Lőj Networks 
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192.168.16.21 




















WS-CLU-DHCP 
















3 
Favorite Targets I Volumes and Devices Í RADIUS 









General ] Discovery Targets 
hég HGrES storage devices for a target, select the target and then dick TETTETETT xx Status: Storage: esze 
Target name: Online 1 Disks - 1 online WS-CLU2 
To see information about sessions, connections, and devices for a target, I ign. 1991-05.com.microsoft:storage-storage-demo-target Alertsz Capacity- Current 
dick Details. nonez Total: 98 MB WS-CLU2 
[V Automatically restore this connection when the computer starts Free Space: 75.29 MB 
Client Access Name: Percent Free: 76.87. Other Resources: 
Targets: [v Enable multi-path WS-CLU-DHCP 1 
A Only select this option if ISCSI multi-path software is already installed 
on your computer. Addi gi 
ign. 1991-05, com. microsoft:storage-storage-, ., . Connected IP E 
Kögőü. [ ési l 1 Addresses - 1 online 











5. ábra. Az ISCSI-adattárolóra épített fürt, működés közben 


fürt virtuális nevét a kí- ! rehozása biztosan sikeres lesz. A fürtözés új- 


vánt diszkekhez, amelyek I donságairól bővebben olvashatnak Lepenye 




















ETT ; - mint offline és formá- I Iamás vonatkozó cikkében. 
zztezti ET lemez BERELT 1 sát zatlan lemezek - így hoz- Ha mindent ügyesen csináltunk, akkor 
lme SS I HzES EGEN A ESNEK] zatemdelődmek Ja "meste: ia ikiszolcálók telepítése tütám egy oranibelül 
EVE gánti sets aaa jalaresn dett gála lelő kiszolgálókhoz. Aki ! már figyelhetjük fürtözött kiszolgálóink mű- 
ISCSI initiator service determine the list of volumes and devices. éa 0 A x ZEKE 
fels szg ba tajt la st teget Tán ANT] szolgálókhoz visszatérve ! ködését. 
CE TE ETKÁN E ; e 3 
az iSCSI Initiatorban el- Somogyi Csaba 
Gt lenőrizzük, hogy az adat (Csaba.Somogyi(Omicrosoft.com) 
zza eküwven TETTE adot SEK TÉETNÜKESTTÉE k 
TE ET TVJ ENNESÜTTEN TT TE ÉTENNESE TEZST TB tárolónk csatlakoztatott Microsoft Magyarország 


állapotban van-e, majd 






























































Er [[//OSSSSS [SAAB] [5] a Volumes and Devices Hogyan TALIN NT) 
fülre kattintva vegyük 
3. ábra. Az iISCSI lnitiator beállítási folyamata fel a köteteket! Ennek A témához rendkívül sok olvasnivalót találhatunk az 
legegyszerűbb módja az interneten, csak ízelítőül néhány hivatkozás, ahol a 
KEZEKET NNa ..-ECBl]P.. a Autoconfigure gomb legalapvetőbb információkat találhatjuk meg. 
E Rea használata. Ezt követően Az ISCSI összefoglalása, sok külső hivatkozással: 
WS-ELU1 az egyik gépen online ál http://en.wikipedia. org /wiki/ISCSI 
MEGY Henev lapotra kell hoznunk a Az 0SI-IS0 modell összefoglalása: 
aza azzzá  Manege Citers. diszkeket, majd inicia- http://en.wikipedia.org/wiki/OSI. model 
CSI Initiator lizálni és formázni kell A SAN összefoglalása: http://en.wikipedia.org/ 

Select véhioh indtiator ta enable for ttés ckastór őket. Amikor ezzel elké- wiki/Storage. area network 

E ETTTTYMONEE TETTETETT szültünk, akkor a meg- A Microsoft SCSI Initiator letöltési oldala: 

JVBLEEL etel Benes eagmntásttekek fős. ] HAGNS ES PRTYBNYALT, osztott diszkjeink már http://www.microsoft.com/downloads /details. 
rendelkezésre állnak, aspx?familyid-12CB3C1A-15D6-4585-B305- 
tehát kezdhetjük a fürt BEFD1319FO25 €displaylang-en 
telepítését. A Windows Részletes, konkrét ISCSI-alkalmazási forgatóköny- 
Server 2008 esetén ez a veket is leíró dokumentum a Microsoft oldalán: 

4. ábra. A fürt hozzáférésének engedélyezése az iSCSI Targeten művelet már rendkívül http://www.microsoft.com/windowsserver2003/ 
egyszerű, hagyatkozzunk technologies storage / iscsi/deployiscsi.mspx 

majd hozzáférést a korábban létrehozott vir- ! bátran a varázslókra. Ajánlom mindenkinek David Woodsmall részletes SCSI-gyűjteménye: 

tuális diszkekhez. a Cluster Validation riport használatát, mert http://home.nc.rr.com/woodsmall/SCSI.htm 


A következő lépésben rendeljük hozzá a ! ha itt nem látunk hibákat, akkor a fürt lét 
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A Fujitsu Siemens Computers áttörő IT infrastruktúra-megoldásai éppoly rugalmasan alkalmazkodnak 
a váratlan helyzetekhez, mint On. 


A Fujitsu Siemens Computers FlexFrame" Infrastructure rendszere tökéletesen illeszkedik az adatközponti 
környezetekbe. Az egyes szoftverfejlesztők által támogatott rugalmas IT-platform dinamikusan rendeli hozzá 

a szervererőforrásokat az egyes alkalmazásokhoz. A nagy teljesítményű, négymagos Intel$ Xeon? processzorral 
ellátott PRIMERGY RX300 szerverekre épülő megoldás minden speciális igényt kielégít az alkalmazások támo- 
gatása terén. Hiba esetén az érintett alkalmazások dinamikus áthelyezésével tartja fenn a zavartalan működést. 
Miért is jó ez Önnek? Mert a kivételes rugalmasságnak köszönhetően végre minden energiájával az üzleti műkö- 
désre koncentrálhat. És ez csak egy a Fujitsu Siemens Computers Dinamikus Adatközponthoz készült innovatív 
megoldásai közül! 


Xeon 
inside" 


Ouad-core. 
Unmatched. 


www.fujitsu-siemens.hu 


Az alábbiak az Intel Corporation Egyesült államokban vagy más országokban használt védjegyei: Celeron, Celeron Inside, Centrino, Centrino Logo, Core Inside, Intel, 
Intel Logo, Intel Core, Intel Inside, Intel Inside Logo, Intel Viiv, Intel vPro, Itanium, Itanium Inside, Pentium, Pentium Inside, Xeon, és Xeon Inside. 
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A PARANCSSOR 
MEGLÓDUL 


Múltad a sötét 
Ablaküvegen sejlik 





Mintha... de mégsem. 


épzeljük el, hogy egy ismeretlen szigeten találjuk magunkat. Éjszaka. Zseblámpa nélkül. 


Elsőre tuti szerencsétlenkedünk egy csomót, aztán kezdjük apránként megtalálni a já- 


ratokat. Valószínűleg nem azokat az ösvényeket fogjuk használni, amelyeket nappal is 


használnánk - de elboldogulunk ezekkel is. Út szerencsére sok van. 


Nagyjából ezt fogja érezni az a rendszergazda is, akit odaültetnek egy Windows 2008 Server 


Core elé. Command prompt. Semmi más. Ha véletlenül becsukja, akkor hiába kaparászik 

















a Start Menu után - az sincs. [jedten nyom egy Ctrl 
AltDel kombinációt - és felcsillan a remény. Egy pici 
grafikus felület. Jelszóváltoztatás. Iask Manager! Huh. 
Indítsuk el gyorsan a teljes grafikus felületet: explorer. 
EXE VI MES. 

Tényleg csak a command prompt maradt. 

Az első sokk után jönnek az emlékek. A netsh... amely 
csak kávét nem főz. Van! Van. Hurrá! KI túdunk törni 
a gépről. De ha a kitörés megy, akkor valószínűleg a be- 
jutás is. Távoli hozzáférések vajon vannak-e? Ez már nem 
megy saját kútfőből, irány a net. Olvasgatni fogunk. 

Sokkal magabiztosabban sétálunk vissza a géphez. 
Netene, csiba! Ismerlek immár, tudom a titkodat. 

Hagyjuk most már magára elképzelt rendszergazdán- 


kat, aki egyre vehemensebben fogja magát be- 


levetni a parancssori élet rejtelmeibe. Boldogulni fog. A feladat csak elsőre ijesztő. 
Ahogy a szólás mondja: az olvasottság időnként csodákra képes. 

Vizsgáljuk meg inkább a koncepciót. 

Miért is jó, hogy kidobjuk az operációs rendszerből a grafikus felületet? (Amellyel 
persze repül egy csomó más is, hiszen izgalmas függőségek léteznek ám egy operációs 
rendszerben.) Javaslom, inkább fordítsuk meg a kérdést: vajon mi szükség van egy 
szervertermékben grafikus felületre? Oké, hogy legyenek benne nagy zöld gombok. 
Egyéb? Hogy lehessen róla netezni? Hamis. Hogy lehessen szerveralkalmazásokat 
futtatni, menedzselni? Nos, igen. Ekkor tényleg kell. De csak azért, hogy egy vagy 
több szerverfunkciót - DNS-szerver, DHCP-szerver, tartományvezérlő, fájlszerver 
- futtassunk rajta, valójában nincs szükségünk grafikus felületre. Igen, tény, hogy 
kényelmesebb kattogtatni. De mekkora árat fizetünk érte? 

a Grafikus felület nélkül sokkal egyszerűbb hardver is elegendő a feladatra. 

Előszedhetjük a spájzból a régi vasakat (erősebb PII, közepes PIID, immár nem 


kell ezeket bagóért elsóznunk más operációs rendszert futtató barátainknak. 512 


Ki 


E Xx 
S 


MB RAM és 5-6 GB merevlemez elég a tel 

jes funkcionalitású Server Core futtatásá- 

hoz. Méghozzá Windows 2008-tudással! 

a Pont olyan részek hiányoznak az operá- 
ciós rendszerből, amelyek kedvenc betöré- 
si célbpontoknak számítanak. Márpedig ha 
nincs az a komponens, nincs rajta keresz- 
tüli sebezhetőség sem. 

a Ha nincs komponens, nem kell foltozni 
sem. Kevesebb patch, kevesebb fejre állás. 
Kevesebb restart. 

a Ha kevesebb komponens fut a szerveren, 
értelemszerűen jóval kisebb a szoftverhiba 
lehetősége is. A megbízhatóság az egekbe 
szökik. 

a. Végül van egy olyan fogalom, hogy gra- 
nularitás. Network-szinten ez azt jelenti, 
hogy külön vason üzemeltetjük mondjuk a 
tartományvezérlőt, másikon a DHCPtszer- 
vert és így tovább. Ez eddig, teljes értékű 
szerverrel, horrorisztikus erőforrás-pazar- 
lás volt 
Jelzem, hogy éppen csak karcoltuk a fel 

színt ebben az írásban. A konkrét megvalósí- 

tás, a kezelhetőség, a kerülőutak mind-mind 
érdekes témák, különösen az öreg motoros 
adminoknak. 

Eme rövid írás a Windows Server 2008 
képességeit bemutató karikatúra-sorozatunk- 
ból származik, ahol tömören, lehetőség sze- 
rint emlékezetesen mutatjuk meg, miért is 
forradalmi az új szerverroperációsrendszer. 
A karikatúrák a www.microsoft.hu/technet/ 


rss.aspx"kampany-karikatura linken érhe- 


tőek el, RSS-ben. 


Petrényi József 
(petrenyi.jozsef(osao.hu) 
SA0-Synergon, MCSE--M, MCITP, MVP 
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A GAL És 


A FREE/BUSY 


Hajlamosak vagyunk megfeledkezni róluk, hiszen csak úgy 


működnek, nem zavarnak sok vizet. Pedig... Ha jobban beleássuk 


magunkat, akkor hamarosan elcsodálkozunk azon, hogy egyáltalán 


működnek. Az Exchange-feilesztők is érezték, mennyire sebezhető 


ez a két rendszer, ezért az Exchange 2007-ben drasztikusan 


átalakították. Mindkettőt. 


em, nem arról van szó, hogy úgy vártam volna az Exchange 2007-et már a gyár ka- 
N pujában, hogy a teherautósofőr vattakabátját rángattam, mi hír van a GAL-ól és a 
Free/Busy-ről. Őszintén szólva, mindketten nagyon sokáig elkerülték a figyelmemet. 
Biztosan működnek, vontam meg a vállam. 
Egy szerencsétlen projektnek kellett beütnie, hogy kiderüljön, mekkora kavarás is történt 
ezen a két területen. 


Kezdjük az elején: mi is egyáltalán a GAL és a Free/ Busy? 


Lerántjuk a leplet a GAL-ról 

A GAL a Global Address List rövidítése. Ez gyakorlatilag egy címlista. Figyelem! Címlista 
- nem terjesztési lista. Az előbbi egy LDAP-lekérdezés eredménye, az utóbbi pedig egy AD-cso- 
port jellegű objektum. (Csakhogy sikerüljön kellően összezavarnom mindenkit, létezik olyan, 
hogy dinamikus terjesztési lista, amikor is a csoport tagsága LDAP-ekérdezés alapján áll ösz- 
sze, dinamikusan.) 

Mint tudjuk, címlistából annyi lehet, mint égen a csillag. Pontosabban annyi, amennyit a 
hálózatunk elbír. Tetszőleges számú LDAP-lekérdezést gyárthatunk, adunk nekik neveket, és 
már készen is vagyunk. Jogos lehet a kérdés, mi különbözteti akkor meg a globális címlistát 
(GAL) az egyszerű címlistától? Ha most rosszindulatú lennék, akkor azt mondanám, az, hogy 
a címlistában egyből megjelennek a változások, a globális címlistában meg nem. Ez sajnos sok- 
szor így van, de azért meglehetősen negatív a megközelítés. 

Igyekszem megmagyarázni, de ahhoz mélyebbre kell merülnünk. 

Addig oké, hogy LDAP-lekérdezések, de milyen adatbázison? Nyilván Active Directory... 
de melyik partíció? Elsőre a Domain lenne a megfelelő, de ne feledjük, az Exchange-organizá- 
ció erdőszintű, tehát az összes doménpartícióra rá kellene futtatni a lekérdezést. Zűrös. Hol is 
vannak ezek az adatok egyszerre jelen? Hát a globális katalógusban. Csökkentsük a terhelést, 
fusson a guery csak a GC-n. Csökkentettünk, de azért annyira nem. Faragjunk tovább. Ne 
egy lépésben történjen a lekérdezés. Legyen egy aszinkron szolgáltatás, amelyik időnként rá- 


futtatja a lekérdezést a címtárra, majd minden felhasználónál bejegyzi a s howInAddressBook 
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tulajdonságba mindazoknak a címlistáknak 
a DNijét, amelyeknek a felhasználó is tagja. 
Természetesen ez egy olyan tulajdonság, mely 
belekerül a globális katalógus leszűkített 
adatbázisába is - így a címlista konkrét lekér- 
dezésekor nem kell azt a bonyolult lekérde- 
zést ráküldeni minden alkalommal a GC-re, 
elég csak a showvIlnAddressList tulajdonságot 
vizsgálni. Gyorsítottunk? Bizony. Cserébe ve- 
szítettünk egy kicsit az aktualitáson, de ez 
már csak hangolás kérdése. A gond az, hogy 
még mindig eléggé igénybe venné a globális 
katalógust az állandó címlista lekérdezése. 
Vizsgáljuk meg, melyik címlistát kérik le leg- 
sűrűbben a kliensek? Hát a globálisat. Akkor 
vegyük ki ennek a címlistának a legyűjtését 
ebből a körből, a maradék címlistákat már el 
tudja látni a GC. 

A különböző disztributálási módszerek 
miatt létezhet az, hogy a változás például az 
All Address List címlistában már megjele- 
nik, de a Global Address Listben még nem. 
Legalábbis nem mindenkinél. 

Gonosz voltam, mi?! Már éppen kezdett 
érthető lenni a magyarázat, erre megint meg- 
csavartam. 

Nos, a helyzet az, hogy nem mindegy, mi- 


lyen klienssel próbálkozunk, és az a kliens 
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1. ábra. A GAL terjesztése Exchange 2000/2003 organizációkban 


milyen állapotba van kapcsolva. A kulcs 
az, hogy ismeri-e a cached módot vagy sem? 
Amennyiben nem, akkor a GAL terjesztése 
ugyanúgy történik, mint a többi címlistáé, 
azaz mindenki a globális katalógust piszkálja 
a lekérdezésekkel. De ha ismeri... nos, akkor 
alapvetően változik meg a helyzet. 

Vizsgáljuk meg az I. ábrát. Látható, hogy 
a non cached módban üzemelő kliens köz- 
vetlenül a GC funkcióval ellátott tartomány- 
vezérlőről szedi le a legaktuálisabb globális 
címlistát. 

Az alsó telephelyen viszont már cached 
módba kapcsoltuk a klienseinket. Most nem 
térek ki rá, miért jó ez nekünk - a lényeg, 
hogy megéri, még ha most éppen nem is az 
lesz a végeredmény. 

Az ábra szerint ekkor a kliens - a betárcsá- 
zós kliensekhez hasonlóan - a Public Fold- 
ers system foldereiből olvassa ki a... nem a 
GAL-), hanem az OAB-ot. Az OAB (Offline 
Address Book) tulajdonképpen egy pillanat 
felvétel a globális katalógusról, miközben az 
jobbról előz, és 32 foggal vigyorog. Nézzük 
részletesebben! 

1. Az Exchange szerver aktivizálja azt a bi- 
zonyos aszinkron folyamatot. Igen, valóban, 
a Recipient Update Serviceről van szó, a jó 
öreg RUS-ról. Ez adja az új felhasználóknak 
megadott minta alapján az e-mail-címeket, és 
ez vezeti át a felhasználók adatlapjára, hogy 
mely címlistáknak is a tagjai. 

2. A RUS teszi a dolgát, a változásokat be- 


leírja a hozzá legközelebb eső tartományve- 
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zérlő doménpartíciójában lévő adatbázisba, 
ahonnan azok átvezetődnek a globális kata- 
lógusba is. 

3. Az Exchange-szerver naponta egyszer 
belerúg az OABGen eljárásba. 

4. Ez az eljárás naponta egyszer lefényképe- 
zi a globális katalógust. A fényképet elnevezi 
OAB-nak. 

5. Az OAB-ot belecsomagolja a megfelelő 
Public Folderbe. (Szerverektől függően más 
az OAB verziója is, ezek különböző könyvtá- 
rakba kerülnek.) 

6. Az egyes OAB-folderek Public Folder- 
replikációval terjednek szét az egész organi- 
zációban. 

7. Végül a kliens kiolvassa a postafiókjához 
legközelebb eső Public Folderből az OAB-ot. 
Ha a postafiókját tartalmazó Exchange-szer- 
veren nincs rajta, akkor a Public Folder 
Referral alapján elmászik más szerverekre 
érte. 

Vagyis az All Address List. mindig Íriss - 
már amennyire a RUS az. A Global Address 
List... hát, az cached módban nem annyira. 
Mekkora eltérések lehetnek? Borzasztóan na- 
gyok. Nem is csoda, az Exchange összes lusta 
disznóját bevonták a folyamatba. 

Kezdjük a RUS-szal. Mikor aktivizálódik? 
A jó ég tudja. Kapunk valami hibaüzenetet, 
ha nem futott le? Persze. Majd. A második 
szereplő az OABGen. Róla legalább tudjuk, 
hogy naponta egyszer fut le, alapértelmezés- 
ben hajnali ötkor. Jön az újabb rém, a Public 


Folderreplikáció. Mikor fut le? Amikor ked- 


2. ábra. A Free/Busy információk terjesztése Exchange 2000/2003 organizációkban 


ve van. Maximum annyit állíthatunk - fol 
derenként -, hogy sürgős vagy nem sürgős a 
replikáció. Alapértelmezésben nem az. Végül 
jön a cached módba kapcsolt kliens. Mikor 
kéri le az OAB-ot? Elinduláskor, utána pedig 
ahhoz képest 24 óránként. Ha feltételezzük, 
hogy a RUS villámgyors (haha) és a PFrep- 
likáció is felszaggatja a betont (muhaha), ak- 
kor is simán összejöhet két nap az OABGen 
és a cached módba kapcsolt kliens összjáté- 
kával. 

Durva? Az nem kifejezés. Éppen megérett 


az újításra. 


A Free/Busy előtörténete 
Már az ókori görögök is meg tudták külön- 
böztetni azt az időt, amikor ráértek csevegni 
az agorán (free) attól az időtől, amikor ép- 
pen más elfoglaltság miatt képtelenek voltak 
meetinget apprúvolni (busy). 

Természetesen náluk is csak akkor műkö- 
dött a rendszer, ha már a szervezkedés során 
rendelkezésükre álltak ezek a Free/Busy in- 
formációk. Nagyjából abban az időben tény- 
kedett az Exchange 4.0-5.5 generáció, az pél 
dául Free/Busy-konnektorokkal oldotta meg 
a feladatot. 

Az Exchange 2000/2003 már annyival 
volt fejlettebb ennél, hogy - az OAB-hoz ha- 
sonlóan - a Public Folderekbe csomagolta a 
Free/Busyinformációkat. Itt speciel nincs 
különbség cached/non cached mód között, 
mindenki a nyilvános mappákból eszik. 


Látható - kék nyilak a 2. ábrán -, hogy 
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amint valaki módosít az Exchange Server 
Information Store adatbázisában lévő ada- 
tain, az egyből beleíródik a Public Folderbe 
is, ahol a PEreplikáció repíti szét az informá- 
ciót organizációszerte. 

Tulajdonképpen ezzel nem is voltak nagy 
gondok, rendesen működött - eltekintve at 
tól az apróságtól, hogy a kliensek 45 per 
cenként kaptak friss adatokat. Az egyetlen 
komoly problémát az okozta, hogy a Public 
Folder halálra ítéltetett, tehát gondoskodni 
kellett a Free/Busyinformációk számára va- 


lamilyen más terjesztési módszerről. 


Az Exchange Server 2007 színre lép 
Nem is akárhogyan. Mondhatni, berúgva az 
ajtót. Amikor kihajította a RUS-t az ablakon, 
akkor a pultnál iszogató adminok elismerően 
bólogattak. Amikor átlyukasztotta a Public 
Folderek fülét, akkor már kezdte felütni fejét 
a nyugtalanság. A pánik akkor tört ki, ami- 
kor egy sorozattal kinyírta az egyik sarokban 
kártyázó összes LDAPlekérdezést. 

Hát... akkor most... mi lesz? 

A válasz az, hogy OPATH. Egyik lekérde- 
zés helyett a másik. Rossz hír a lengyel logika 
kedvelőinek, hogy ez a filter már normális. 


Hasonlítsuk csak össze: 


LDAP Avery: (£(objectCategory—user) 
(displayname—IT)) 

OPATH: ( ( ObjectCategory -like "user" ) -and 
( DispolayName -like "IT" ) ) 


Mindkét lekérdezés legyűjti az összes fel 
használót, akinek displayneve úgy kezdődik, 
hogy [I. 

Elsőre nem rossz az új filter, szerintem 
sokkal olvashatóbb. Külön öröm, hogy el 
van látva bőségesen operátorral, teljesen Ct 
jellegű a kicsike. Csakhogy. Amíg az LDAP 
(2uery közvetlenül tudott hivatkozni a cím- 
tárobjektumokra, ez az OPATH-ból hiány- 
zik. Számomra felfoghatatlan okból közééke- 
lődött egy metanyelv. Például nem mondha- 
tom azt, hogy PhysicalDeliveryOfficeName , 
az van helyette, hogy Office. Nem írhatom 
azt, hogy "mail, azt kell írnom, hogy "Win- 
dowsEmailAddress". Miért? Nem tudom. 

Nos, mitől is lesz ez itt véresen aktuális? 
Ugye, azzal kezdtük, hogy a címlisták, bele- 
értve a GAL- is, egy-egy LDAP-gueryből áll 


nak. Azaz még bele sem telepítettük az első 
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HEJ 


H] 16:52:47 Central Europe Standard Time Central Europe Daylight / 
ime; 0771571601 00:36:49 Central Europe Standard Time Central 
Europe Daylight Time; 
; msExchMinádminyYersion: -2147453113; 
a 




















msExchüueryFilter: (Alias -ne $null -and 
((((f(Obje ss -eg "user" -or ObjectClass -eg "contact) -or 
ObjectClass -eg "msExchSystemMailbox -or ObjectClass -eg 
"msExchDynamicDistributionList) -or ObjectClass -eg "group" -or 
ObjectClass -eg "publicFolder7]; 

08 msExchLastáppliedRecipientFilter: (Alias -ne $null 
and [((((ObjectClass -eg "user" -or ObjectClass -eg "contact) -or 
ObjectClass -eg "msExchSystemMailbox -or ObjectClass -eg 
"msExchDynamicDistributionList) -or ObjectClass -eg "group" -or 
ObjectClass -eg "publicFolder7]; 
12 msExchRecipientFilterFlags: 3; 
12 msExchYersion: 4535486012416; 
12 msExchűueryFilterMetadata: 
Microsoft.Exchange12.8191d340bc0c4á7e4b4058a479602f94c:Rec 


ipientFilterType-1; 
63 msExehPurportedearchut: 


Microsoft.PropertyW/ell. OueryString-(£(mailNickname-"J(j(object 
Classzuserj(objectClass-contactjfobjectClass-msExchSystemM 
ailboxj](objectClass-msExchDynamicDistributionListj(fobjectClas 
szgroupj(objectClass-publicFolder]]): 

Microsoft.Propertywell Items-0; DsOuery EnableFilter-0; 
DsÖuery YViewMode-4868; 

Commonűuery Form-E33FEES83D957DOT1B9320O0OAOZ4AB2ZDBB; 
Commonluery Handler-5EE62384C231D0O11891COOAO24AB2D 











3. ábra. A GAL objektumai 


Exchange 2007 szerverünket az organizáció- 
ba, már meg is állt a telepítés: konvertálj em- 
ber, ha jót akarsz! 

Természetesen lehet manuálisan is. [dő- 
milliomosoknak és mazochistáknak. A leg- 
több szokványos címlistához némi internetes 
keresgéléssel már megtalálhatjuk az OPATH 
szűrőfeltételt - köztük a GAL-hoz is. Lesznek 
olyan szűrőlisták, amelyeket konvertálás he- 
lyett egyszerűbb lesz összekattogtatni az Ex 
change 2007 varázslójával (5. ábra). Egyedül 
a régi egyedi címlistákkal leszünk bajban, ott 


nem ússzuk meg a kézimunkát. Szerencsére 
itt is van könnyítés, Bill Long írt egy remek 
Powershellbszkriptet, amely a legtöbb LDAP- 
filtert képes OPATHiilterré konvertálni. 
(Google: , Bill Long" OPATH convert.) 

Ja, természetesen ahol nem működik a 
varázsló, oda a megfelelő cmdlet kell az Ex 
change Management Shellben, jelen esetben: 
setaddresslist, és a recipientfilter paraméter- 
be kell belegyömöszölni a filtert. 

Tulajdonképpen készen is vagyunk. Pusz- 
tán csak figyelmeztetésképpen mondom, 
hogy ha a setglobaladdresslist paranccsal 
egyszer sikeresen módosítottuk a GALt, ak- 
kor akár el is felejthetjük: a Powershell több- 
ször nem engedi. Jobb észnél lenni. Vagy gon- 
dolkodni. Hol is tárolódnak ezek a lekérde- 
zések? A címtárban. Nézzük meg LDP-vel, mi 
mindene is van egy GAL-objektumnak? 

Láthatjuk, hogy ott virít az msExchan- 
geOueryFilter tulajdonságban az OPATH- 
filter, ugyanaz valamiért ott van az msExch- 
LastAppliedRecipientFilter tulajdonságban 
is - és ott figyel az msExchPurportedSearch- 
UI tulajdonságban a régi LDAPfilter is. 

Nyilván ADSIEdittel az első tulajdonság 
módosítható. (De hogy ez mennyire lesz össz- 
hangban a másik két tulajdonsággal, nem tu- 


dom. Élesben nem teszteltem.) 
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4. ábra. A globális címlista terjesztése Exchange 2007 organizációban 


KK 






— INFRASTRUKTÚRA 


Nos, akkor megvan az új GAL-ilter, él a 


2007-es organizációban a globális címlista. 


A GAL terjesztése az Exchange 2007 
organizációban 

Már csak el kellene juttatni a kliensekhez, de 
úgy, hogy ugye nincs RUS, és lehetőleg ne le- 
gyenek érintve a Public Folderek sem. Akkor 
mi az, amink van? Web. XML. És van egy sze- 
repkör, amely ezekben nagyon profi: a Client 
Access Server, a CAS. Ez az a szerepkör, ame- 
lyet sokan úgy azonosítanak, hogy ,ja, az 
owa", majd legyintve kilökik a DMZ-be. Hát 
nem. Mint az alábbi példákon is látható lesz, 
a CAS igen rendesen részt vesz az organizáció 
hétköznapjaiban. (Mindamellett persze tény- 
leg azonos az OWA-val is.) 

Száz szónál is szebben beszél egy ábra, in- 
kább nézegessük azt (4. ábra). 

Itt alapvetően két folyamot szeretnék rész- 
letesen bemutatni. Az első arról szól, hogyan 
készül el, és hogyan jut el a terjesztési pont 
rá az OAB, 

1. Az Exchangecszerver belerúg az OAB- 
Gen folyamatba. Alapvetően naponta egy- 
szer, de ez átállítható folyamatosra is. 

2. Az OABGen lefényképezi a globális 
címlistát, és legyártja az OAB-verziókat. 

3. Az OAB-példányokat kirakja a Public 
Folderekbe, a régi kliensek számára. 

4. Az OAB-adatokból az OABGen legyárt 
egy XML fájlt is, és ezt kiteszi egy fájlmeg- 
osztásba 

5. A CAS szerveren futó OAB website 
időnként ránéz erre a megosztásra, és felkap- 
ja a kirakott fájlt. 

Tessék észrevenni, hogy a folyamat itt már 


nem a RUS-szal indul. Mint írtam, aszink- 





rön RUS. immár nincs, 
Ehelyett rögtön akkor, 
amikor egy felhasználó 
adataiban változás tör 
ténik, és  rányomunk 
az OK gombra - vagy 
Exchange Management 
Shell esetén rátenyere- 


lünk az Enter billentyűre 





-, rögtön kiértékelődnek 
az organizáció címlis- 
táiban lévő OPATH-iL 
terek, az eredményként 
kapott címlisták DN-ér 
tékei pedig beíródnak a 
showlnAd- 


dressBook tulajdonságá- 


felhasználó 
4 alur1 


[Ti 


ba. (Megjegyzem, ilyen 
tulajdonsága nemcsak 
a felhasználónak lehet, 
hanem mindenkinek, 
aki e-mailcímet kaphat 


egy  AD-erdőben,  az- 





az tagja lehet a címlis- 
táknak. Részletesebben 
lásd az 5. ábrát.) 

Eljutottunk odáig, hogy az OAB-informá- 
ciók kint vannak a CAS OAB websiteján. 
De hogyan fognak odatalálni a kliensek? 

Ekkor lép be a képbe az Autodiscovery 
szolgáltatás. Nagyon fontos elem, megérdem- 
li, hogy egy kicsit hosszabban is foglalkoz- 
zunk vele. 

Amikor Exchange 2007-telepítés előtt pre- 
paráljuk a címtárat, létrejön egy úgynevezett 
Service Connection Point, azaz SCP. Ide 
van bejegyezve, hogy mely gépeken fut Auto- 
discovery szolgáltatás. Persze a preparálás- 


kor még nem, de a CAS 





New Address List 


[d Introduction Introduction 


[7 Users with Exchange mailboxes 

5 Users with external e-mail addresses 
I Resource mailboxes 

5 Contacts with external e-mail addresses 


I Mail-enabled groups 





5. ábra. Új ámlista létrehozásakor választható lehetőségek 
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funkció telepítésekor az 
Autodiscovery értékei 


már beíródnak. 


ük This wizard alloves you to create a new address list. Address lists display a subset of , 
mécs recipients in an organization based on properties of the recipient. Természetesen ezeket 
4 Schedule , j , , : 
MENÉS te az értékeket módosítani 
etisömnelétjon is lehet, nyilván a Shell 
Container: 
h Browse ] ből (6. ábra). 
Include these recipient types: Teh át amikor egy 
C Noone 
C  Allrecipients types Outlo ok 2007-kliens 
c he ölögng pEGHE BE] kancsolódai sók 
, 


akkor azt találja, hogy 
az Autodiscovery szol 


gáltatás elérésével kap- 





csolatos információk 


- a 6. ábra szerint - a 


naláuthenticationMeth- 
1Ur1 


3 : eartn [ 5CODe: MIIKy way .UNIYerse 
] C:Documents and Settingstádministrator:get-clientacce 


assName 
ernaluri : h 


ABvirtualDírectory? 





7. ábra. Az 0AB-website paraméterei 


https://earth.milkyway.universe/Autodiscov- 

er/Autodiscover.xml fájl letöltésével állnak 

majd rendelkezésére. (HTIPS ugyan, de az 
alaptelepítéskor a CAS-szervernek csak self 
signed tanúsítványai vannak.) 

Mit is tud ez az Autodiscovery szolgáltatás? 
Gyakorlatilag ő a recepciós. Mindenkiről 
tud mindent, leginkább azt, hogy egyáltalán 
van-e az illető, és ha igen, akkor hol talál 
ható. Olyan az Exchange-kliensek számára, 
mint a Windows-klienseknek a DNS. Hogy 
egész pontos legyek, a visszaadott XML fájl 
nagyjából a következő információkat fogja 
tartalmazni: 

a Hol található a csatlakozni szándékozó fel 
használó MAPLprofilja (Mailbox Server, 
login name, autentikációs mód)? 

a Hol találhatók az OAB-információk? 

a Hol találhatók a Unified Messaging-szolk 
gáltatások? 

a Hol fut az Availability webservice (Free/ 
Busy, OOF)? 

x Mik az Outlook Anywhere-beállítások? 
Csak az első pontról sűrűn teleírt olda- 

lakat lehetne regélni, mennyi könnyebbsé- 

get jelent majd ez a rendszergazdáknak... de 


most kihagyom a ziccert. Koncentráljunk in- 


kább az OA B-elérésre. 


Microsoft TechNet 
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show Metwark Connectivity Changes 


show Mevv Hail Desktop Alert 





Connection status. : a 


Test E-mail AutoConfiguration. , , 


Hide v4hen Minimized 








8. ábra. Kapcsolódási teszt 


Ebben a történetben az Autodiscovery fel 
adata összesen annyi, hogy megmondja a 
hozzáfordulóknak, merre található az OAB- 
információkat szolgáltató website. 

A 7. ábrán látható, honnan veszi az Auto- 
discovery az adatokat. A setoabvirtualdirec 
tory parancsban lehet az -iinternalurl/-exter- 
nalurl paramétereken keresztül befolyásolni, 
milyen címekről érhető el a CAS-szervereken 
futó OAB-weboldalunk. 

Egy újabb döbbenet. Igen, ez az egész mó- 
ka működik az internet felől is. 

Na de... úgy indult a történet, hogy Active 
Directory, azon belül SCP-objektum... Az 
interneten viszont nincs kint a címtárunk. 
Legalábbis remélem, hogy nincs. 

A trükk az, hogy ha az Outlook 2007 nem 
talál SCP-objektumot, akkor a hasára üt, és 
bepróbálkozik két címmel. (És ez nemcsak 
akkor igaz, ha odakint vagyunk, ez történik 
akkor is, ha például nem tartományi tagként 
használjuk a gépünket.) Tegyük fel, hogy 
az enailkcímem userl.O(9cegnev.hu, ekkor a 
következő címekkel fog kísérletezni (9. ábra): 

https://cegnev.hu/Autodiscovery/ 
Autodiscovery.xml 

https://autodiscover.cegnev.hu/ 


Autodiscovery/Autodiscovery.xml 


Test E-mail AutoConfiguration 









Exchange 2 
Clien Access 


Exchange 1 
Mailbox 












HUB Transport 


Outlook 2003 
Cached mode 


Outlook 2007 
Cached mode 







Outlook 200x 
Non-Cached mode 













ke 








10. ábra. A Free/Busy információk terjesztése Exchange 2007 organizációban 


Semmi más dolgunk nincs, mint szerezni 
egy megfelelő - értsd: valódi, külső - tanú- 
sítványt, majd a fenti címek valamelyikén 
publikálni a CAS-szerverünk Autodiscovery- 
weblapját. Természetesen ebben az esetben az 
egyes szolgáltatásoknál meg kell adni, milyen 
címeken lesznek elérhetők kívülről. (Lásd a 
7. ábrán az -externalur]l paramétert.) 

Jól elkalandoztunk. Térjünk most vissza a 
4. ábrához. Az egyik folyamatot már részle- 
teztük, most akkor vizsgáljuk meg, hogyan is 
talál el a kliens a weblaphoz: 

1. Vagy a címtártól, vagy a DNS-től meg- 

kérdezi, hol fut az Auto- 


discovery szolgáltatás. 





E-mail Address ! petrenyi. jozsefffexternet.hu 


2. Megkapja a választ. 











Password ..00000—0——.—. 








! Results ! L09 XIML 


Vagy a DNS-től, vagy az 
SCP-objektumtól. (Több 


CAS-szerver esetén alap- 








Autodiscover to https: /fexternet.hu/autodiscover/autodiscover.xmi starting 
Autodiscover to https: /f/externet.hu/autodiscover /autodiscover.xmi FAILED (0x800€8203) 
Autodiscover to https: //autodiscover.externet.hu/fautodiscover/autodiscover.xmi starting 


Local autodiscover for externet.hu starting 
Local autodiscover for externet.hu FAILED (0x8004010F) 
Redirect check to http: //autodiscover.externet.hu/autodiscover /autodiscover.xmi starting 


Srv Record lookup for externet.hu starting 
Srv Record lookup for externet.hu FAILED (0x8004010F) 





Autodiscover to https: //autodiscover,externet.hu/autodiscover /autodiscover.xmi FAILED (0x800€8203) 


Redirect check to http: //autodiscover.externet.hu/autodiscover /autodiscover.xmi FAILED (0x80072EE7) 


helyzetben véletlenszerű 
választ ad vissza a DC. 
De be lehet konfigurálni 
site-érzékeny válaszra is.) 

3. Elmegy az Autodis- 


covery-szolgáltatáshoz, 





és megkérdezi hol fut az 














9. ábra. Autoconfiguration-teszt 


JANUÁR-FEBRUÁR 





OAB-webszolgáltatás. 
4. Az Autodiscovery 





átküldi neki a részletes választ XML formá- 
tumban. 

5. A kliens elmegy a megadott címre, elké- 
ri az OAB-adatokat tartalmazó XML fájlt. 

6. Az OAB-website odaadja neki. 

Ennyi. Nem mondanám, hogy egyszerűbb 
lett - de minden komponens úgy teker, mint 


egy versenymalac. 


§ Internet Intormatian Services (II51 Manai 


I § Internet Information Services 
E-wI EARTH (local computer] 
EH Application Fools 


E-1 web §ites 

: E fálb Default web Site 
H-lg Autodisoover 
H-üly EwS 
HA Exadmin 
EH- Exchange 
ely Exchweb 
HH- Microsolt-5 erver-Achlvesyne 
EH DAB 
H-lly owa 
HA Public 
HH- d Rpc 


ET aspnet elient 
BH-d eb Service Extenslons 


a RpewithCert 
El-e ég LnifiedMessagina 











IT. ábra. A CAS-szerver webszolgáltatásai 
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: Ews (Default Web Site) 
HG Le ed 
: ÍNtlmt 
: False 
: False 
earth.milky 
: gram Files. 
: EARTH 


: https ://earth.mi Ikywway.univer sejEws/Exchange . asmx 
§ 2. Aj — 


jectCategory 
objectclass 


whenchanged sala alzágke Bi ak 
whencreated sala alijga saint 





12. ábra. Az Availability szolgáltatás konfigurálása 


Ilyenkor a rendszergazda első kérdése: mit 
tehetek, ha nem működik? Azt már láthat 
tuk, website-oldalon hogyan olvashatjuk ki, 
illetve módosíthatjuk az értékeket. De mi 
van akkor, ha valamiért az Outlook mégsem 
találja a címeket? 

A tálcán lévő Outlook ikonra CTRL--jobb- 
klikk akcióval rárepülve a 8. ábrán látható 
menüt kapjuk. Itt kiválasztjuk a , Test E-mail 
AutoConfiguration" menüpontot, a felugró 
ablakban beírjuk az e-mailcímünket, jelsza- 
vunkat, töröljük a GuessSmart opciókat - és 
tesztelünk egyet. 

A 9. ábra be is mutat egy teszteredményt. 
Remekül látható, hogy az Externet még nem 
készült fel az Outlook Anywhere-publikálá- 
sokra. (Valószínűleg nem Exchange 2007-et 
használnak.) De látható az is, hogy a kliens 
mi mindennel próbálkozik, mielőtt feladná. 

Amennyiben sikerült volna a csatlakozás, 
a Results fülön láthatnánk, hogy milyen 
adatokat kaptunk vissza az XML fájlban. 
Ezekből rögtön látszik az egyes szolgáltatások 
elérhetősége - legalábbis az, hogy a kliens 


mit kap, hol keresse azokat. 


A Free/Busy információk terjesztése 
az Exchange 2007 organizációban 
Az eddigiekhez képest a Free/ Busy informá- 
ciók terjesztésének elmagyarázása már kelle- 
mes lejtmeneti séta lesz. A fontos fogalmakat 
az előző fejezetben tisztáztuk, itt csak az elté- 
résekre kell koncentrálnunk. 

A részleteket a 10. ábrán láthatjuk. Vannak 
ugyan változások, de ránézésre nem túl na- 
gyok: OABxwebsite helyett például Availabi- 


lity szolgáltatás van. Nosza, vessünk csak egy 


Li) 


, CN-HumanRac 
gurat1o0n , DC-m 


xchvirtualDírectory, 


zIUIZ 


Usér Z 
wants User 8 
calendar 
information 
for particular 


elera Fleet tineframe 


tclientácc 


Ferformancé 
öptimizatián 
thróugh 
caching 


msExchwebServicesvirtualDir 


Recurrence 
expansian and 
processing 





Return 
inforrnatiór 
ta llser zs 

client 
camputer 


pillantást a CAS webol 
dalaira és keressük meg 
(11. ábra)! 

Látjuk itt az Avail 


Awvailability service 


ele , , 7? : 
ability szolgáltatást? En sslési 


information 
for all ather 
regüested 
USérs 
(A, B, étc.) 


igen. De annyira nem 
magától értetődő. Az 
Availability szolgáltatás 
ugyanis nyitott. (Áll egy 
Availability APLból és 
egy erre épülő webser 
vice-ből.) Bárki fejleszt 


atart 
Availability 
service 


het saját programot rá. 


7 [ Availability service 


and other 
technigues LL. / 


informatian 
for A 






Awvailability 
Service 
CdiSCOVErs 
users Íree 
and busy 
infőrmatián 


User Z 
specifies 
the lével 
öf detail. 


Reguest As 
calendar 
infőrmatiön 


Fár all 
reguésted 
USErs 

(A, B, etc.) 


Retrieve 
status and 
start/end 
tirne fram 
ms mailböx 
. [Frege and 


Busy security 


model 


.  [6- Detailed 


Retrieve 
status, 
start/end 

time, 
subject, 
locatrion and 
importance 
Írom 
65 mailbox 


Check the 
a permissions 
7 granted to 
ZbyA 






Retum 
] Ppérmissións 
8 granted to 
Give ZhbyA 
MINT UN 
(reguésted, 
granted) 
pérmissions 


action 


Service initialization 


F—— HE 


Register 
service 





Ebből kifolyólag nem is 
kapott külön website-ot, 
hanem az Exchange Web Services (EW5S) 
alatt található meg, services.wsdl néven. 

Miután kiismertük, már tudjuk, hogyan 
kell konfigurálni (12. ábra). 

Látható, itt is van mind internalurl, mind 
-externalur]l paraméter - azaz ez is működhet 
kinti eléréssel is. 

Térjünk vissza még a 10. ábrára. Feltéte- 
lezem, a 4. ábra alapján mindenki számára 
érthető a működési mechanizmus, legalább- 
is, ami a kliens hozzáférését illeti. Az adatok 
begyűjtése viszont némileg más lett: habár 
kompatibilitási okokból megmaradt a Public 
Folderbe csomagolás is, de a CAS-szerver, 
pontosabban az Availability webservice már 
közvetlenül fordul a Mailbox szerverhez, 
mégpedig MAPLn keresztül. A mechaniz- 
must részletesebben a 13. ábrán tanulmányoz- 
hatjuk. 

Én legszívesebben nem is tennék hozzá sem- 
mit, az ábrán minden gyönyörűen látható. 


Mi maradt még a végére? Összefoglalunk. 


13. ábra. Az Availability szolgáltatás működési vázlata 


Látható, hogy az új terjesztési módszereknek 
rengeteg előnyük van: up-to-date információ- 
kat szolgáltatnak a klienseknek, méghozzá 
gyorsan, emellett lehetővé teszik a külső hoz- 
záféréseket is. Ellenben a terjesztési metódus 
nem lett egyszerűbb, az Exchangerendszer- 
gazdáknak rendesen képbe kell kerülniük, 
ha nemcsak üzemeltetni akarnak, hanem 
olykor hibát is elhárítani. 

De a legnagyobb hátrányról még nem 
beszéltem: a fenti metódusok csak akkor 
működnek, ha szerveroldalon minimum Ex 
change 2007 van, kliensoldalon pedig mini- 
mum Outlook 2007. Minden más esetben a 
régi terjesztési módszerek maradnak - azaz 
felkészülhetünk rá, hogy még jó ideig kevert 
rendszerekkel kell együtt élnünk, ahol mind- 
két bonyolult rendszer egymás mellett fog 
működni. 

Petrényi József 
MCSE--M, MCITP, MVP (petrenyi.jozsef(sao.hu) 
SA0-Synergon 
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DELL - Új generációs szalagos mentési megoldások 


A szalagos mentés napjainkban döntő szerepet játszik a tárolási és mentési tervek 
kidolgozása során; ideális megoldást biztosít tárolási és archiválási folyamatokra. 

Az LIO-4 technológia bizonyítottan minimális kockázatot, magas szintű megbízhatóságot 
és rendelkezésre állást biztosít megfizethető áron! 


A Dell volt az első a piacon az LIO-4 technológiával; megoldásokat kínál a kis vállalkozások 
részére, egészen az adattároló központokig. Ez az új meghajtó kategóriájában az első, mely 


eszköz szintű titkosítást kínál. 


Duplázza meg mentési kapacitását és csökkentse az adattárolását a Powervault" LTO-4- 


120 meghajtók és könyvtárak segítségével! 


PowervaultM 
LIO-4-120 szalagos meghajtó 
relülmúlhatatlan teljesítmény és kapacitás 
- Kapacitás: 300 Gb natív 
- Teljesítmény: adatátvitel 120 MB/sec 


- Biztonsági jellemzők: WORM (Wright 
Once-Read-Many), eszköz 
szintű titkosítás 


- Interfész: SAS 3 GB/s, FC 4 GB/s 


Iparági standardok 


Az első LIO meghajtó 
eszköz szintű titkosítással 


Az LIO-4 az első szalagos mentési 
technológia, mely lehetővé teszi az eszköz 
szintű titkosítást, ezáltal csökkentve az 
üzleti szempontból kritikus adatokhoz való 
engedély nélküli hozzáférés kockázatát. A 
kazetta hordozhatóságának köszönhetően, 
a központtól távol (off-site) is tárolható. A 
PowerVault" LTO-4 megoldások egyaránt 
védelmet biztosítanak helyszíni (on-site) és 
egyéb (off-site) adatvesztés ellen. 
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Standardizált LIO technológia biztosítja a kompatibilitást visszamenőleg és a jövőre vonatkozóan is, valamint a szállító semlegessé- 
get. Az LTO-4-120 kompatibilis az LIO-3 technológiával (olvassa és írja is az LIO-3 mentéseket), illetve olvasáskompatibilis az LIO-2 


mediával. 
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W tSséső 


IISZ A SERVER 
CORE-ON ÉS 
A HOSTING 


A Windows 2008 Server egyik radikális 


újítása a Server Core konfiguráció, 





amelynek használatával csak minimális 

telhasználói felületet kapunk, így igen 

kicsi erőforrás-felhasználású kiszolgálót 
építhetünk. 


z IIS7 is üzemeltethető Server Core-on, ennek telepítéséről és konfigurálásáról lesz szó 
ebben a cikkben. A Server Core az egyik legérdekesebb fejlesztés a Windows-kiszolgá- 
lók történelmében, elvégre egy Windows (ablakok) nevű operációs rendszer pont az 


ablakot dobja le magáról. Nem paradox ez egy kicsit? 


Bevezetés 
Valójában arról van szó, hogy sokan jelezték a Microsoftnak: Hölgyeim/ Uraim, minek ne- 
kem Explorer meg Aknakereső, amikor én egy Active Directory-kiszolgálót akarok üzemel 
tetni? Nem is annyira persze a passzívan diszken levő Pasziánsz zavar minket, hanem azok az 
állandóan futó szervizek, amelyekre nincs szükség az adott szerepkör futtatásához. És ha már 
csökkentjük a memóriafelhasználást, minek nekünk GUI, ha jó volt a parancssor 40 éven ke- 
resztül a UNIX-okban? Egyesek persze úgy érzik, ez visszafejlődés, ez nem a hippikorszak már, 
ha egyszer kitalálták a GULt, minek nekünk újra parancssor? 

Akiknek viszont korlátozottak a hardver-erőforrásaik, és/vagy szeretnek scriptelni, azok 


örömmel vágnak bele egy új kalandba. 


IISZ telepítése Server Core-ra 
De hogyan álljunk neki? Kiindulásként tételezzük fel, hogy van egy frissen telepített Server 
Core-unk, amire még semmilyen szerepkört nem telepítettünk fel. 

Az első (és utána folyamatos) meglepetés az, hogy nincs GUI, így nincs Add/ Remove Programs 
sem a Control Panelen (nincs Control Panel sem, csak egyes appletek működnek). Hogyan kell 
így telepíteni bármit is? A Package Managerrel, a pkgmgr.exe-vel. A jó öreg checkboxok helyett vi- 


szont gépelni kell, de veszettül, hogy összeszedjük a szükséges IIS7-komponenseket. 


VÉ 


T 


De előbb engedélyezzük a Remote Admin- 
istrationt, hogy ne kelljen a gépteremben fa- 


gyoskodni: 


cscript gowindir9ovsystem32N S CRegEdit.wsf /ar 0 


Most már mehet minden távolról, kényel 
mesen. Leginkább az a jó benne, hogy az in- 
terneten olvasott scripteket bemásolhatjuk 
az RDP-ablakba, nem kell annyit gépelni. 

Az alapvető IIS-komponensek telepítése: 


start /w pkgmgr /iv:IIS-WebServerRole; WAS - 
WindowsActivationService:WAS-ProcessModel 


A start /wlait] azért kell, mert a pkgmgr. 
exe azonnal visszatérne, és a háttérben 
aszinkron módon futna. Mivel azonban sem- 
milyen triviális visszajelzésünk sincs a te- 
lepítés állásáról, nem tudnánk, mikor ért 
véget. A /w miatt a start parancs megvár- 
ja, amíg véget ér a pkgmgr processz futása, 
addig blokkolja a hívót, azaz a Command 
Promptot. 

A /iu az Install Update rövidítése, az 
adott Windows-komponenst a /uu Uninstall 
Update kapcsolóval lehetne leszedni. 

Milyen csomagokat választhatunk ki? Az 
oclist.exe segítségével megnézhetjük a Win- 
dows Foundation Package tartalmát, hogy 


ebből mi van és mi nincs telepítve: 


Installed:IIS-WebServerRole 


1— Not Installed:II5-FTPPublishingService 


1— Not Installed:IIS-FTPServer 


Installed:IIS-WebServer 


[ 
[A 
1 Installed:IIS-ApplicationDevelopment 


EN 
j 1— Not Installed:IIS-ASP 


Szép, konzolon kirajzolt fa, tisztára Norton 
Commandermnosztalgiám van tőle. € 

Ebből a listából tehát kinézhetjük, mit le- 
hetne még feltelepíteni. 

Tegyük fel, szükségem van még a Windows 


Authenticationre, az lemaradt az előbb. 


start /w pkgmgr /iv:IIS-WindowsAuthentication 


Egy másik gépről böngészővel ránézve már 


látszania kell a demó-főlapnak. A Core-on 


ir 








nincs Internet Explorer sem, habár, mond- 
juk, egy third-party böngésző éppen el tud raj- 


ta futni. De ez nem illik egy Server Core-hoz. 


Mi érhető el a Core-on? 

Miden, ami nem igényel .NEI Framework- 
öt. Így ezek sajnos nem mennek: 

nm [IS-ASPNET 

IIS-NetFxExtensibility 


a IIS-ManagementConsole 


a [I5S-ManagementService 


IIS-LegacySnaplIn 
IIS-FI PManagement 
WAS-NetFxEnvironment 


WAS-ConfigurationA PI 
Azaz megy a klasszikus asp, és megy a php 


vagy más scriptnyelvek futtatása, a korábbi 
számban ismertetett FastCGLvel is. 

Fájdalom, de az IIS Manager .NET Frame- 
work (WinForm3s) alapú, így az is kiesett. De 
hát ez egy konzolos oprendszer, ugye nem fe- 
lejtettük el? 

De nem térek ki a logikus kérdés elől. 
Miért pont az ASP.NE Let hagyta ki a Micro- 
soft az IIS7 Server Core-verziójából? Nos, a 
.NET Framework ablakmentesítése messze 
nehezebb, mint azt kívülállóként gondol 
nánk. A legtöbb ember nem is sejti, milyen 
bizarr helyeken is ablakok mocorognak a 
háttérben, például hálózati programozásnál, 
amikor egy deka ablak sincs a közelben. 
Nem tudom megmondani, hogy egy szerviz- 
csomaggal jön-e ki az ASP.NELtámogatás 
majd, vagy csak a következő szerverrel (in- 
kább az utóbbi eset a valószínű), de nyilván 
ez sokakat érdekelni fog majd. Jelen pillanat 
ban szerintem statikus lapok és php-scrip- 
tek futtatására fogják legtöbben használni a 
Server Corett. 

A távoli adminisztráció sem megy, mert 
ahhoz a Management Service-nek kellene 
futnia, amit szintén .NEL-ben írtak. Azaz, itt 
az ideje kicsit közelebbi barátságot kötni az 


appcmd.exe-vel. 


Élet IIS-admin GUI nélkül 


Derítsük fel, mit kaptunk az alaptelepíté- 


sünkkel - az appcmd.exe felhasználásával. 


HAWindowstystem32Vnetsrv— appcmd list sites 
SITE , Default Web Site" (id:1,bindings:http/":80-, state:Started) 


Remek, van egy website-unk, a jól ismert 


Default Web Site, amely minden címen a 





(ca. Administrator: HÁ Windowsisystem32icmd.exe 


H:AWindouwuwsXSyustemzZzNinetsrujzappcemd list apppool /text: 
ÁPPPOOL 
ÁPPPOOL . NAME: "Def aultÁppPool" 
PipelineMode:"Integrated" 
Runt imeVersion: 
state:"Started" 
ET Ér A 
name : "Def aultÁáppPool" 
gueueLength: "1888" 
autoStart: "true" 
enable32BitAppünW!4in64:"false" 
managedRunt imeVersion: 
enableConf igurat ionÜverride:"true" 
managedPipe lineMode : "Integrated" 
passAnonymousToken: "true" 
IprocessModel1l 
identityType : "NetworkService" 
userName : 
password: "" 
loadUserProfile:"false" 
manualGroupMenmbership:"false" 
idleTimeout : "98 :29:09" 
maxProcesses:"1" 
shutdownT imeLimit : "98 :H1:38" 
startupT imeLimit : "BA :B1:38" 
pingingEnabled:"true" 
pinglInterval:"88:BA:39" 
pingResponseT ime : "BA :B1:38" 


"ecyecling1] 
disallowOverlappingRotation: "false" 
disallouRotat ionOnConf igChange: "false" 
logEventünRecycle:"Time, Memory. PrivateMemory" 
IperiodicRestart 1] 

memory: "Ag" 

privateMemory: "8" 

s 


reguests:"B8 
time:"1.85:88:008" 
Ischedule1 
EZ KIP Z- 
loadBalancerCapabilities:"HttpLevel" 
orphanWyWorkerProcess:"false" 
orphanfáctionExe : 
orphanAáctionParams:"" 
rapidFailProtection:"true" 
rapidFailProtectionlnterval:"88:85 : 89" 
rapidFailProtectionMaxCrashes:"5" 
autoShutdownExe : 
autoShutdownParvams :"" 
[cpul 
limit :"8" 
action: "Nofction" 
resetlnterval:"88:85 :a8" 
smpAff initized:"false" 
smpProcessorfff inityuMask:"4294967295" 
smpProcessorfff inityuMask2:"4294967295" 








H:AWindousXSustemi2zlNinetsrul 





I. ábra. Életkép a Server Core-on: IIS-alkalmazások 
adatai 


80-as porton érhető el. Milyen alkalmazás 


van mögötte? 


appcmd list app 
APP. Default Web Site/" (applicationPool:DefaultAppPool) 


Nézzünk utána, hogyan van beállítva a 


DefaultAppPool. 


appcmd list apppool 
APPPOOL , DefaultAppPool" (MgdVersion: MgdMode: 
integrated, state:Started) 


No, ez nem túl sok infó, de várjunk csak: 


appcmd list apppool /text:" 
APPPOOL 
APPPOOL.NAME:"DefaultAppPool" 
PipelineMode:"Integrated" 
RuntimeVersion:" 
state: Started" 
[add] 
name: DefaultAppPool" 
gyevelength:"1000"7 
autostart: true" 
enable3ZBitAppOnWin64:" false" 


[processModel] 
identityType:"NetworkService" 


Ha már unjuk a fekete ablakot nézni, ak- 


kor persze át is lehet irányítani a parancsok 


kimenetét fájlba (meg persze meg lehet vál 


toztatni a konzol háttérszínét is): 


appcmd list apppool /text? 5 apps.txt 


A kapott szövegfájlt aztán megnézhetjük 
... notepaddal. Bizony, a notepad fut Server 
Core-on. Mi következik ebből? Az, hogy 
közvetlenül is lehet konfigurálni az IIS7- 
et, a konfigurációs állományain keresztül. 
Gyors módosításokat garantáltan könnyebb 
így végrehajtani, mint szétgépelni magunkat 
a commandi:ablakban. 

Mondjuk, szeretném átköltöztetni a log- 
könyvtárat a System partícióról egy másikra, 
hogy DOS-támadás esetén nehogy megtölt 
sék a rendszerpartíciót, ezzel leállítva a szer 


vert. Appcmd-vel ez így nézne ki: 


appcmd set config -section:]log 
/centralW3CLogFile.directory:cxXtemp 


Nem begépelni nehéz ezt, hanem kitalál 
ni, hogyan címezzük meg a módosítandó 
node-ot az XML-fában. 

Ezzel szemben notepadban megnyitva az 
applicationHost.configot csak át kell írni 


ezt a SOTt: 


ZcentralW$CLogFile enabled— "true" directory— 
"O/gSystemDrive9olinetpub logstLogFiles" /— 


Ezzel csak azt akartam megmutatni, hogy 
nem feltétlen kell mindent parancssorból 
megoldani, csak azért, mert Server Core-on 


vagyunk. 


PHP -- FastCGI Server Core-on 
A PHP futtatásához szükség lesz a CGILmo- 
dulra, ebben van a FastCGLtámogatás is. 


Már tudjuk, mit kell tenni: 
start /w pkgmgr /iv:1IS-CGI 


A PHPinterpreter telepítéséhez le kell tölt 
teni a php-csomagot, majd kicsomagolni és 
bemásolni a megfelelő helyre. Ezek bizony 
kihívások Server Core-on, hisz nincs sem 
böngésző, sem shellbe integrált zip program 
(hisz shell sincs). 

Ha megtehetjük, töltsük le és csomagoljuk 
ki a dolgokat egy másik gépen, és másoljuk 
fel a Server Core-gépre egy megosztáson ke- 


resztül. A PHP xxx Non-thread-safe Win32 


Microsoft TechNet 











Ti " 


binaries PHP zip csomagot (http://www.php. 
net/downloads.php) töltsük le, hisz pont az 
az előnye a FastCGLnek, hogy nem szálbiz- 
tos, nincs benne szinkronizáció, de emiatt 
gyorsabb, a FastCGI az alkalmazásokat úgyis 
biztonságban, egy szálon futtatja. 

Csomagoljuk ki valahová, ez nálam a HG 
PHP könyvtár lett. 

A PHP-kkönyvtárban levő PHP.INIRe- 
commended fájlt át kell nevezni php.inire. 
Ezután az IIS-nek megmutatjuk, hol van a 


phpifuttató: 


AppCmd set config /section:system.webServer/fastCGI /-7- 
[fullPath— hAphpwwhp-cgi.exe ] 


Majd a .php kiterjesztéshez beállítjuk a 
FastCGLfuttatót, és a script interpretert: 


AppCmd set config /section:system.webServer/handlers /-- 
[Iname— PHP-FastCGTpath—"".php verb —""" modules— 
"FastCgiModule" scriptProcessor— h:Aphpvphp-cgi.exe 
resourcelype— Fither ] 


Teszteljük le a művünket egy hello.php- 
val, amelyet, mondjuk, notepadben szerkesz- 
tünk meg, és a wwwroot könyvtárba men- 


tünk el: 
C?php echo "Hello World! ?— 


Az oldalra böngészve (egy másik gépről) 
máris látható a komplex phpxwebalkalma- 
zásunk. 

És hogy az egész életszagúbb legyen, ha 
valaki például wordpress nevű blogmotort 
szeretne Server Core-on futtatni, azt minden 
további nélkül megteheti, mondjuk MySOL- 
háttérrel, minimális vason. 

Ez az egész Server Core lényege: sallang- 
mentes, minimális konfiguráció egy nagyon 
jól behatárolt cél érdekében. 


Hosting IIS7-en 
A következőkben leírtak csak egy része vo- 
natkozik a Server Core-ra, az ASPNETspe- 
cifikus információk egyelőre csak a normál 
Windows 2008-ra értendők. 

A hosting eléggé mostohagyermek volt 
a Microsoft háza táján, a korábbi IIS-ekkel 
nehéz volt egyes hosting-feladatokat szépen 
megoldani. A hosting azt jelenti, hogy va- 
laki hardvererőforrásokat bérel egy hoster 
cégtől, amelyeket persze valamilyen operá- 


ciós rendszeren és szoftvereken keresztül ak- 
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náz ki. Itt most elsősorban a webes tartalom 
hostingjáról beszélek, de gyakori az adatbá- 
zis, a levelezés, a víruskeresés, a biztonsági 
mentés és egyéb szolgáltatások hostolása is. 
Webhosting esetén három életképet érdemes 
külön tárgyalni: 

1. Osztott hosting: egy gép erőforrásain 
sok website osztozik 

2. Dedikált hosting 

3. Webfarm 

Jelen cikkünkben az elsővel foglalkozunk 
részletesen, a harmadikra pedig még vissza- 


térünk egy későbbi számban. 


Osztott hosting 

A mai hardverek óriási erőforrás-tartalékok- 
kal rendelkeznek, így egy masina akár több 
száz kisebb forgalmú website-ot is ki tud szol 
gálni egyidejűleg. Kivéve, ha valamelyik site 
kisajátítja magának a gépet. Osztott hosting 
esetén tehát a kihívás a bérlők közötti erő- 
források igazságos elosztása. Milyen erőfor- 
rásokról van szó? 

Memória. 32 bites világban ez volt az egyik 
leggyorsabban elfogyó erőforrás. Tételezzük 
fel, hogy egy gépen 100 felhasználó website- 
ját hostoljuk. Legyen a maximális 4 gigabájt 
RAM a gépben, és olyan az alaplapunk, hogy 
látja az oprendszer az egészet. /3GB kapcso- 
lóval is 1 gigabájt az oprendszeré, így marad 
nekünk 3 gigabájt. Fejenként ez 30 mega- 
bájtot jelent. Ez nem sok ám! Egy kisebb 
ASP.NET-alkalmazás memóriafelhasználása 
is simán felszalad 100 megára, azaz könnyen 


elfogyhat a memória. 64 bi- 





Nézzük, milyen megoldások szolgálják a 
fenti pontokat az [IS7-ben! 

Osztott hosting esetén az a tipikus, hogy 
minden bérlő részére létrehozunk egy 
Windows-felhasználót. Ez lehet AD-felhasz- 
náló vagy sima SAM-user, első körben ennek 
nincs jelentősége. Az IIS6-tal szemben ennek 
a felhasználónak nem kell semmilyen speciá- 
lis csoporttagságot kapnia, röptében megad- 
ja a szükséges tagságot az IIS, amikor indítja 
az alkalmazást. 

Mindegy egyes webalkalmazás részére 
létre kell hozni egy Application Poolt. Az 
AppPool definiálja azt, hogy milyen para- 
méterekkel indul el és fut a webalkalmazást 
kiszolgáló worker processz, a továbbiakban 
wp (w3wp.exe). Iehát minden tárhely egye- 
di felhasználók nevében, egyedi processzek: 
ben fut. Ha valamelyik processz feldobja a 
bocskort, az nem zavarja a többi bérlő web- 
alkalmazását. 

A memória túlzott igénybevételét is képes 
korlátozni az IIS. Az AppPoolnak meg lehet 
adni, hogy ha a wp memóriafelhasználása 
egy beállított méret fölé emelkedik, akkor 
indítsa újra a processzt (2. ábra). Meg lehet 
adni virtuálismemória-korlátot és a private 
memória korlátját is. A private az a rész egy 
processzben, amit a Windows nem tud meg- 


osztani több processz között is. Például a ker- 


nel32.dIl kódja minden wp-be betöltődik, az- 
az mindegyik virtuális memóriáját szaporít 
ja, de mivel valószínűleg osztott a processzek 


között, ezért a private memóriát nem növeli. 





tes architektúrákon persze 


lötyögnek az alkalmazások 


E Recycling 


a memóriában, ott már ke- 
vésbé gond ez. De még itt is 
ügyelni kell arra, hogy igaz- 
ságos legyen a memóriael 
osztás az ügyfelek között. 
Processzor. Egy végtelen 
ciklus, és máris intenzíven 
ki van sajátítva a proci. Az 
ilyen nyilvánvaló igazságta- 


lanság ellen védenie kell a 





webszervernek a jól viselke- 
dő webalkalmazásokat a bi 
torlóktól. 

Diszkterület. Egyrészt korlátozni kell tud- 
ni a felhasználható tárterületet, másrészt 
meg kell akadályozni, hogy egymás adatai 


hoz hozzáférjenek a bérlők. 


Sdvanced Settings 


Disable överlapped Recycle 
Disable Recyclina for Configuration Changes 
caenerate Recycle Event Log Entry 
Private Memory Limit (KE ü 
Regular Time Interval (minutes) 
Reguest Lirnit 
specific Times 
virtual Memory Lirnit (KEB1 ü 





Private Memory Limit ÍKB) 
[privatelemory ] Haximum amount of private memory in KEY a worker process 


can consume before causing the application paci ta recycle, 8 value of Ü me. , , 








zo) 


False 
False 


174ü 
ü 
TimesSpan[ ] Array 


ak 1 Cancel - 


zé 


2. ábra. Memóriakorlátozások beállítása 


Azért valószínűleg, és nem bizonyosan, mert 
ha egy másik DLL van betöltve arra a címre, 
amit fordításkor megadtak a kernel32-nek, 
akkor az OS Library Loadernek relokálnia, 


LVA 


, 





E CPU 
Lirnit öctiör Külly3p 
Lirnit Interval (minutes 1 5 
Fracessor öfFinity Enabled 
Fracessor öFfinity Mask, 


False 
Jag 7Za5 


Limit 


time, 





Sdvanced S5ettings 79 xI 


[dirnit ] CanFigures the maximum percentage af CPU time (im 1/1üü0üths aF a 
percenti that the worker processes in an application pool are allamed ta 
consume over a periad af time as indicated by the CPLI Limit Interval 
property, IF the limit set by the CFU Limit property is exceeded, an event is 
written ta the event lag and an optianal set of events can be triggered asz 
determined by the CFU Lirnit öction property, setting the value of this 
property ta ü disables limitina the worker processes ta a percentage of €PLI 





Advanced S5ettings 


Haximurn Failures 


Frotectiar, 





3. ábra. A processzorhasználat beállításai 


módosítania kell a DLL kódját a memóriá- 
ban, ami így nem lesz azonos a nem relokál 
takkal, így nem lehet megosztani. 

Vigyázni kell ezekkel a számokkal, mert 
csalókák lehetnek. Egy 500 megabájtos vir- 
tuálismemóriadlimit látszólag nagyon magas, 
ennek ellenére egy kisebb ASP. NET-alkalma- 
zás is pillanatokra képes felhízni ekkorára, 
köszönhetően a lusta Garbage Collectornak 
és a sok (az előfordítás miatt szerencsére osz- 
tott) .NET rendszerkomponensnek. A pri 
vate memória talán jobban jellemzi, mennyi 
re sokat eszik az alkalmazás. A lényeg, hogy 
csak tapasztalati úton lehet belőni ezeket a 
számokat, és lehet, hogy lesznek alkalma- 
zások, amelyeknek egyedi értékek kellenek, 


nem elég nekik, ami a többségnek elegendő. 


Onvédelemből sztrájkolnak 
a munkások 
Mit érzékelnek a wp újraindításból az al 
kalmazások? Sajnos azt, hogy az in-processz 
adatok, statikus változók adatai - ASP.NET 
Cache, ASP.NET Session stb. - elvesznek. 
Ha valaki kitöltött egy hosszú formot, majd 
az elküld gombra nyomva visszautasítja az 
adatok elmentését, mert lejárt (megsemmi- 
sült) a Sessionje, akkor bár sokat fog minket 
emlegetni, de garantált, hogy nem jön vissza 
többet az oldalra. Emiatt a szolgáltatónak 
érdemes elgondolkodnia valamilyen outof 
processz tárolási lehetőségen, legyen az adat 
bázisban tárolt Session vagy maga az adatbá- 
zis mint szolgáltatás. 

Történelmi adat, de IIS6 esetén az operá- 
ciós rendszer korlátoltsága miatt legfeljebb 


körülbelül 60 wp tud csak párhuzamosan 


E Rapid-Fail Protection 
"service Unavailable" Respünse Type 
Enabled 
Failure Interval (minutes 5 


shutdown Executable 
shutdown Executable Parameters 


Haximurm Failures 


[rapidFailFrotectionőMaxűrashes] Maxirnum number aF worker process 
crashes permitted before the application pool is shut down by Rapid Fail 








HttpLevel 
True 


- 


CK I cancel I 


s 


4. ábra. Rapid-Fail Protection, az IIS önvédelme sorozatos hibák esetére 


futni, ennél többet csak a biztonság rovására 
lehet engedélyezni (UseSharedWPDesktop). 

A processzor kisajátítása ellen beállítha- 
tó, hogy ha a wp adott ideig (Limit Interval) 
adott résznél több procit evett (Limit), lőjék 
le a wp-t. A 3. ábrán az van beállítva, hogy ha 
több mint 5 percig 20 százaléknál több pro- 
cit használ a wp, kigyilkolják azt. 

Vigyázni kell vele, mert lehet, hogy mond- 
juk egy képnézegető alkalmazásnál, ami röp- 
tében számol valamit egy nagyobb kép feldol 
gozása során, túllépi a limitet, és aztán jön a 
kapuzárási pánik. 

A wp önvédelméhez még hozzátartozik az 
is, hogy ha túl sűrűn és/vagy sokszor leáll 
hibával a wp, akkor letiltja azt az IIS (4. áb- 
ra). Ez egy jó szolgáltatás, másképp, ha nincs 
engedélyezve, lehet, hogy gyorsan betelik az 
event log, ha egy alkalmazás állandóan el 
száll. ASP.NEIprogramozók azt gondolják, 
ó, hát én nem használok unmanaged kom- 
ponenseket, énmiattam nem szállhat el a 
wp. Én is azt hittem, míg az élet rám nem 
cáfolt. NET 2.0-tól kezdve, ha egy háttér- 
szálban történik kivétel, a teljes managed 
AppDomaint leállítja a CLR (1.1-ben ez még 
nem így volt, sunyin elszállhattak a háttér- 
szálak). Ha leáll az AppDomain, leáll a wp. 

Ha leáll a wp, azt a Rapid-Fail Protection 
bajként érzékeli, és elindítja hóhér számláló- 
ját. Még jön 4 felhasználó a következő 5 perc 
ben, és máris letiltódik az app, ahonnan már 
csak a rendszergazda hozhatja vissza. 

Háttérszálakat sok esetben használunk, 
még ha nem is tudunk róla, például Timerek 
alkalmazása esetén, vagy tudatosan, aszink- 


ron metódushívásoknál delegate-ek haszná- 


latával. Az a baj, hogy az ASP.NET keret 
rendszer csak azon a fő szálon kapja el a ke- 
zeletlen kivételeket, amin a lapot elindította, 
a háttérszálakon nem. Tessék erről mesélni 
a fejlesztő kollégáknak, barátkozzanak a try- 
catch-csel. 

A diszkterület védelme a Windows NIEFS 
beépített (0uota rendszere miatt egyszerűen 
beállítható. Azt kell átgondolni, hogy kötet 
vagy mappaszinten állítjuk be a korlátozást? 
Ha a teljes kötetre, akkor védettek vagyunk 
az ellen, hogy a  webalkalmazás programozot 
tan telerakja a temp könyvtárat vagy bármely 
más helyet, ahová csak van joga írni. Viszont 
nem várt módon lehet, hogy kevesebb helyet 
kap így a bérlő, mert az ASP.NET átmene- 
ti fájlokat ír a rendszerpartícióra, így ha az 
ugyanazon a köteten van, mint az adatok 
(nem ajánlott, természetesen), akkor ez is vi 


Szi a ( Juotát. 


Teljes elszigetelés 
A másik megfontolandó kérdés, hogyan véd- 
jük egymástól a webalkalmazások adatait? 

Alapfelállásként ajánlottam, hogy min- 
den wp saját account nevében fusson. Az 
ASP.NET kódok a wp-fiók nevében futnak. 
Statikus fájlokhoz viszont nem a wp-felhasz- 
nálónak, hanem az IUSR új beépített fel 
használónak kell olvasási jog, mert ezt szemé- 
lyesíti meg a wp alapértelmezett módon. 

Ez azonban problémás, mert így az én site- 
omon futó kód el tudja olvasni a szomszédok 
tartalmát, mert nekik is ugyanaz az IUSR 
van beállítva olvasási joggal. Ezért érdemes 
minden felhasználó esetén átállítani, hogy 


Anonymous hitelesítés esetén az AppPool 
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hoz beállított fiók nevében érje el az IIS a 
webes tartalmat, így már nem lehet belekuk- 
kantani a szomszéd adataiba (5. ábra). 
Milyen jogok kellenek ezek után az 
AppPooltfelhasználónak a tárhely könyvtá- 


Elnternet Information Services (IIS) Manager Hiz] Ég 
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Name A Í Status 

önonymous öuthentication Enabler 
ösP.NET Impersonation Disable 
Basic öuthentication Disable 
Forms öuthentication Disable 
windows Authentication Disable 
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5. ábra. Az anonymous felhasználók nem IUSR, hanem a wp felhasználója 


nevében olvassák a tartalmat 


rára! Nyilván, hogy oda csak neki legyen jo- 
ga írni, meg persze a szokásos Systemnek és 
Adminstrators csoportnak. 

Ez jó, mert az alkalmazás tud adatokat 
tárolni maga mellett közönséges fájlokban. 
Rossz viszont, hogy egy rosszul megírt ASP. 
NELweboldal segítségével saját ASP.NELol 
dalt is írhatnak a fájlrendszerbe, amit távol 
ról meghívva már kódot is tudnak futtatni a 
gépen. Ebből baj lehet. Nem jó, ha egy web- 
lap maga mellé tud írni. 

Ezért szerencsésebb, ha csak olvasási joga 
van a wptt futtató fióknak a bérelt könyvtár- 
ra. Ebben az esetben viszont ki kell alakíta- 
nunk egy olyan könyvárat minden felhaszná- 
ló részére, ahová van írási joga, de nem érhe- 
tő el a webszerveren keresztül. Ide írhatják az 
átmeneti fájljaikat, kis adatbáziskáikat stb. 

Ez elég biztonságos megoldás, de akkor 
még megoldandó probléma a tartalom feltöl 
tése. A feltöltéshez nincs kézenfekvőbb, mint 
az új FTPszerver, amit az előző számban ala- 
posan kielemeztem. Amit most át kell gon- 
dolni, hogy milyen jogok kellenek a felhasz- 
náló könyvtárára, hogy az FIP-n keresztül 
tudjunk tartalmat feltölteni? Ha Windows- 
hitelesítést használunk az FTP.szerveren, ak- 
kor sajnos beleütközünk az előbb tárgyalt di- 
lemmába, elég-e az olvasási jog a könyvtárra, 
vagy kell írás is?" Windows-hitelesítés esetén 


kell írásjog, hisz ilyenkor a wp-t is futtató 
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felhasználó nevében írja az FTP-szerver is 
a fájlokat. Jobb megoldás lehet, ha minden 
felhasználó kap egy IIS-felhasználót is, és 
annak engedélyezzük az írást a tárhelykönyv- 
tárra. Ekkor az írás a Network Service nevé- 
ben történik (az IIS-feL 
használó nevében nem 
történhet, hisz az egy 


nem létező felhasználó a 


Disable Windows Security szem- 
EdEÉ s; 


e Help 


Online Help 


pontjából), így csak an- 
nak kell módosítási jog 
a felhasználói könyv- 
tárakra. Hogy ne tud- 
junk írni más könyvtá- 
rába, arról gondoskodik 
az FTP-kiszolgáló User 
Isolation szolgáltatása. 

Mint említettem, osz- 
tott hosting esetén szin- 
te kötelező minden site- 
hoz saját AppPoolfió- 
kot létrehozni. Ha még- 
se tennénk, és mondjuk minden az alap 
Network Service/IUSR nevében futna, még 
az ilyen esetekre is van védelem az IIS-ben, 
hogy legalább a központi konfigot ne tudják 
szétbarmolni a site-ok, illetve - némi plusz 
munkával - hogy egymás adatait se tudják 
elérni. Emésszük ezt! Bár ugyanannak a fel 


használónak a nevében fut több wp, mégsem 
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tudják elérni egymás adatait. Hogy oldották 
ezt meg? 

A wp alapban Network Service-ként in- 
dul, majd megszemélyesíti az IUSR-felhasz- 
nálót. Ha valaki kiadja a RevertloSelf APL 
hívást, akkor visszacsinálta a megszemélyesí- 
tést, és máris Netwotk Service-ként futtathat 
kódot. Illetve, ha valaki beállítja az 5. ábrán 
látott módon az Anonymous hitelesítést az 
alsó opcióra, akkor még Revert sem kell. 


fióknak, példánkban a 


NetworkService-nek volna joga írni a köz- 


Ha a közös 


ponti konfigot, nagy baj lenne. Persze, alap- 
ban nincs, ezen nem is szabad változtatni. 
Hogy biztosan ne firkáljon bele, a következőt 
teszik. Egyik alkalmazás sem látja az eredeti 
applicationHost.configot, hanem mindegyik 
csak egy másolatot lát belőle. A másolat 
.. Ninetpubvttempvapp- 
Pools könyvtárban keletkezik, és csak az 


a wp indulásakor a 


Administrators/System kombónak van mó- 
dosítási joga rá. A wp-t a következő paramé- 
terekkel indítják el (Process Explorerrel vagy 


Process Monitorral nyerhető ki ez az infó): 


w3wp.exe . . . -h "H:Ainetpubltemplapppoolsl! 
BelaPoolja config" -ap , BelaPoolja" 


A trükk most jön. A wp-be induláskor 
beinjektálnak egy kézzel összerakott SID- 
et. Ez látható a 6. ábra jobb felső részén, a 


v:632 Prupcrtcs 
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6. ábra. Egyedi SID a konfiguráció védelmére 





Process Explorer mutatja meg nekünk: az IIS 
APPOOLSBelaPoolja SID. Hangsúlyozom, 
nincs ilyen felhasználó a Windows felhasz- 
nálói adatbázisában, ez egy mesterségesen 
létrehozott custom SID. A 6. ábra jobb alsó 
sarkában látszik, hogy ennek a SID-nek ad- 
nak olvasási jogot (de még ennek se többet) a 
másolt konfigra. Ezzel az igen fejlett trükkel 
teljesen elszigetelték egymástól a wp-ek által 
látott központi konfigurációs adatokat. 

Ugyanezt az elszigetelést mi is alkalmaz- 
hatjuk a felhasználó webtárhelyének könyv- 
táraira. A szokásos mappajogosultság-beállí- 
tás során használhatjuk az AppPool SID-et, 
azaz a BelaPoolja-t, és ennek kell olvasási 
vagy módosítási jogot adni, az egyedi wp-fel- 
használónál tárgyalt módon. 

Azaz, úgy el tudjuk szigetelni egymástól a 
tárhelybérlők adatait, hogy mégis mind azo- 
nos felhasználó nevében futó wp-szel van el 
érve. Azért ez ügyes. Nem kicsit, nagyon. 

Mindezek ellenére én a sokfelhasználós 
AppPoolmodellt javaslom, az valamivel 
könnyebben kezelhető. 


Jogosultságok 

Az eddigiekből látható, hogy alaposan át kell 
gondolni, melyik wp kinek a nevében fut, 
hogy a lehető legbiztonságosabb módon véd- 
jük a felhasználók adatait. Nem triviális a 
feladat, de kezelhető. 

Ha ASPNETLalkalmazásról van szó, ak 
kor még ráadásul van egy plusz védelmi szin- 
tünk, a .NET Framework saját biztonsági 
rendszere, a Code Access Security. Ez telje- 
sen független az operációs rendszer saját biz- 
tonsági rendszerétől, a managed kódnak elő- 
ször ezen kell átmennie, és aztán még jön az 
oprendszer saját jogosultságellenőrzése is. 

A részletek mellőzésével: arról van szó, 
hogy finoman szabályozhatjuk, milyen mű- 
veleteket hajthatnak végre a weblapok prog- 
ramjai. Alapban Fulllrust van beállítva, az- 
az a NET biztonsági rendszere nem akadá- 
lyoz meg semmilyen műveletet. Tárhelyszol 
gáltatók tipikusan lejjebb veszik a biztonsági 
szintet, általában Mediumra. Ebben a web- 
lapok kódja alapban csak az alkalmazás sa- 
ját könyvtárába tud írni, máshová nem. 
Hálózati kapcsolatokat nem tud létesíteni 
kifelé, unmanaged kódot nem tud hívni (na- 
ná, azonnal hatástalan lenne a CAS), és még 
jó pár egyéb szigorítás, azaz semmilyen veszé- 


lyes dolgot nem tud művelni. A pontos jogo- 


sultsághalmaz persze testre szabható, amire 
sokszor szükség is van. 

Például Medium esetén nem engedélye- 
zettek az OleDB-szolgáltatón keresztüli adat 
elérések, így például Access adatbázist nem 
tud az ügyfél használni. Persze, jó oka volt er- 


re a Microsoftnak, hisz egy bugos OleDB pro- 





configokkal módosítható. Így az új konfigu- 
ráció beállítása egyszerűen egy új web.config 
felmásolását jelenti a tárhelyre. 

Az IIS7-ben precízen beállítható, hogy al 
kalmazásonként mit lehet módosítani és mit 
nem. Például letilthatjuk, hogy bekapcsolják 
a Windows-hitelesítést, mert ha az alkalmazás 


még meg is személyesíti a távolról 





Advanced Settings 


E Process Model 


Identity CustomForWebHosting 


Idle Tirne-out (minutes) 20 
False 
Maxirmurn worker Processes 1 


Load User Profile 


Ping Enabled True 
Ping Maximum Response Time (sec 90 
Ping Period (seconds) 30 
shutdown Time Limit (seconds) 90 
Startup Time Limit (seconds) 90 


Load User Profile 


identity, 





7. ábra. Az Application Poolt futtató fiók profile-betöltésének 
szabályozása 


vider natív kódjára nem érvényes a CAS, így 
bármit megtehet a gépen (az operációs rend- 
szer biztonsága persze rá is vonatkozik, erről 
már volt szó). A hálózati elérés korlátozása is 
zavaró lehet, hisz így például egy online RSS- 
olvasót sem lehet írni. Iermészetesen lehet 
engedélyezni akár egyedi címekre, akár min- 
denre, hogy ki tudjon szólni az alkalmazás. 

Egyes ügyfelek teljesen jogosan szeretné- 
nek használni valamilyen unmanaged kom- 
ponenst is, például valamilyen saját üzleti 
számítást végző COM-komponenst. Ehhez 
sajnos meg kell adni az Unmanaged futtatá- 
si CASJogot, ezzel viszont kinyitjuk Pandora 
szelencéjét, gyakorlatilag már nem építhe- 
tünk a CAS-ra. Jól látszik, nem egyszerű 
kompromisszum ez a használhatóság és a biz- 
tonság között. 

De gondoljunk arra, hogy nem .NEI-web- 
alkalmazásoknál eleve csak az az operációs 
rendszer biztonságára alapozhatunk. 

Osztott hosting esetén át kell gondolni a 
konfigurációkezelés kérdését is. Az az ideá- 
lis, ha a felhasználók mindent be tudnak 
állítani maguknak, ami nem veszélyes a szer- 
verre vagy a többiekre. Ebben ideális partner 
az IIS7 modularizált konfigurációkezelése, 
amelyben nem csak az ASP.NET, hanem az 


IIS konfigurációja is elosztott, egyedi web. 
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belépett felhasználót, akkor remek 
felületet biztosított a hackereknek 
az Administrator találgatásos jel 
szófeltörésére. De gyakran engedé- 
lyezzük a Default Document beál 
lítási lehetőséget, hogy ne csak de- 
fault.htm lehessen a főlap, hanem 
mondjuk index.php. 

A bérelt 


azonban nemcsak a web.config ké- 


site konfigurálása 


(loaduserProfile] This setting specifies vihether IIS loads the user profile for 
an application pool identity, when this value is true, IIS loads the user profile 
for the application pool identity, Set this value to false when vou reguire the 
IIS 6.0 behavior of not loading the user profile for the application pool 


zi módosítgatásával történhet. Az 
IIS Managert le lehet tölteni már 
XDP-hez is, és ezzel be lehet menni 
A — a hoster gépen található tartalom- 
ra. HTTTS, azaz titkosított csator- 
nán történik az adminisztráció, a 
felhasználó saját Windows- vagy 
IIS-fiókjával. Az admin felület persze a hát 
térben a személyes web.configot írja. 

Egyes alkalmazások építenek az őket fut 
tató felhasználó profiljára, azaz feltételezik, 
hogy van például könyvtár a lokális adatok, 
a dokumentumok stb számára. Ezek ugye 
a profile-ban tárolódnak. Az IIS7 alapban 
nem tölti be az AppPool felhasználó profil 
ját, mert a legtöbb esetben nincs rá szükség, 
és jelentősen lassítja a wp indulását. Ha vala- 
mely alkalmazás mégis szeretne profilt hasz- 
nálni, akkor be lehet kapcsolni ennek betölt 
tését (7. ábra). 


Zárszó 

A Windows 2008 Server Core érdekes új 
irányvonal a Windows-termékpalettán, amely 
ígéretes lehetőség a jövőbeli specializált, kis 
erőforrás-igényű webalkalmazások számára. 
Az IIS7 jól láthatóan erősen fel lett ké- 
szítve a hosting igénybevételre, így ez az első 
olyan IIS-verzió, amely kényelmesen hasz- 
nálható sok tárhely egy gépen történő ki 

szolgálására. 
Soczó Zsolt 
MCSD, MCDBA, ASP.NET MVP 
(http://soci.hu) 
Research Engineer 
Nvalification Development Kft. 
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Cégük valószínúleg sokat költ biztonsági szoftverekre. De biztos, hogy ez elég ahhoz, 
hogy értékes adatvagyonukat biztonságban tudják? 

Egy tény a sok közül: a CERT 2007-es E-Crime Watch felmérésében résztvett cégek 
4999-át érte támadás. Ez 1199-os növekedés az előző évhez képest. 





Ethical Hacking a NetAcademiánál! 


A NetAcademia Oktatóközpont a világon elsőként etikus hekker minősítést kiadó EC-Council 
kizárólagos magyarországi képviselője, és egyben Ethical Hacking tanfolyamának hivatalos 
oktatócége lett. Hallgatóink egy világszerte elismert és egyedülálló tematika alapján sajátítják 
el az információvédelem új szemléletű és hatékony módjait. 


Az Önök cégénél van már CEH szakember? 


Az Ethical Hacking tanfolyam elvégzése után a hallgatók 

CEH minősítést (Certified Ethical Hacker) szerezhetnek. 

Ez a tanúsítvány a világon mindenütt egyértelműen 

bizonyítja, hogy a cím birtokosa megfelelő tudással és 

tapasztalattal rendelkezik a hálózatok és számítógépek eves 
biztonsági réseinek feltárásában és a hatékony 

információvédelem kialakításának területén. 





Ethical Hacker 





A tanfolyam legközelebbi időpontjai: március 31., április 21. 


Az Ethical Hacking tanfolyam elvégzése a CISA, CISM és CISSP minősítéssel rendelkező hallgatóknak 
30 CPE pontot ér. 


További információért kérjük, látogasson el honlapunkra (www.netacademia.net/ethical), 
vagy keresse Szántó Zoltánt (1/472-1214). 


je e a d 
Ethical Hacking Konferencia 


A NetAcademia 2008. április 24-én, az országban első alkalommal Ethical Hacking 
Konferenciát tart. A gyakorlati példákkal színesített minitanfolyam jellegű rendezvény 
ízelítőt ad a rendszereket érő támadásokból, és az ezek elleni védekezésből. 

Az elismert szakembergárdát felvonultató konferencia előadói között az EC-Council is 
képviselteti magát. 


További információ és jelentkezés a konferenciára: www.netacademia net/konferencia 
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A HŐSÖK 


köztünk (élnek) 


Testet ölt a Microsoft szerverek új generációja 2008 tavaszán. 

Legyen Ön is jelen, amikor elsőként kilép a magyar közönség elé a Microsoft 
Windows Server 2008, a Microsoft Visual Studio 2008 és a Microsoft SOL Server 
2008. Értesüljön elsőkézből az újdonságokról, találkozzon személyesen 

a szakértőkkel és próbálja ki a szoftverek új lehetőségeit! 


Értesüljön (az elsők között) 


— Windows Server 2008 termékbejelentő party és szakkiállítás 
— Visual Studio 2008 termékbejelentés 
— SOL Server 2008 termékbejelentés 
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